Originally posted by liam
View Post
Announcement
Collapse
No announcement yet.
Testing EXT4 & Btrfs On A Serial ATA 3.0 SSD
Collapse
X
-
-
Originally posted by Ruud Koot View PostAs space_cache and (ironically) nossd almost always seem to improve performance, it would be nice to know how btrfs performs with a combination of mount options. E.g., would btrfs + space_cache + nossd + compress=lzo get closer in performance to ext4 for the SQLite benchmark?
Comment
-
Originally posted by Cova View PostThe Vertex 3 is a sandforce-based drive is it not? If so, the enabling filesystem-level compression will prevent the sandforce controller from doing any compression which will have a large effect on the benchmark results. While still a fair test as it is a combination a user could end up with, I would also like to see results from a non-sandforce drive.
Comment
-
What about ZFS?
The comparison was very informative and useful, Michael.
However, an argument could be made that BTRFS lags behind EXT4 for the simple reason that the checksumming and healing power it offers is simply costing something. I think it would help the comparison a lot if Debian/kFreeBSD (or native FreeBSD) was installed in the same machine, and the benchmarks were run under ZFS, too.
That way, BTRFS would be compared to ZFS, which has similar features: checksums, snapshots, etc.
Just my 2c.
Comment
-
Originally posted by liam View PostYou're assuming performance is the raison d'etre for btrfs, but the big gain would be in the snapshotting. You would no longer have unrecoverable systems due updates. You would be able to safely update your system from release to release without doing a reinstall (this doesn't mean the update would work but it would mean that it would be safe). These are ease of use features that would be fantastic to have and that's ignoring the data assurances it provides.
Comment
-
Copying files shouldn't introduce latency in your desktop experience.
However I don't really think that we will find 100% of the problem in the kernel since I have never seen a server drop latency do to heavy I/O so perhaps our window managers access the disk more than they should and that is why is the cause of these latencies when there is high I/O. Or the I/O system gets completely clogged up so there can be no I/O over for keyboard and mouse (they are I/O operations as well).
And this not that far fetched since we all remember the Firefox + ext3 fsync fiasco. Who would think before that that Firefox would have latencies due to disk activity...
Comment
-
EXT4, BTRFS, NTFS-3G & NTFS-W7 ... please.
The supposedly superior EXT4 does not have encryption nor compression. NTFS-3G is not the same as NTFS-W7, but BTRFS is, with compression, file-permissions, multiple-dates, & encryption.
Personally all my data & archive files are NTFS-W7 (which differs from previous versions of NTFS). Linux, which I use for most functions, most times, uses EXT4 partitions, but creates many incompatibilities with NTFS-W7: non-MS file names, multiple same-name files & seemingly rare & random write errors onto compressed NTFS-W7 partitions.
Comment
-
Originally posted by gregzeng View PostThe supposedly superior EXT4 does not have encryption nor compression. NTFS-3G is not the same as NTFS-W7, but BTRFS is, with compression, file-permissions, multiple-dates, & encryption.
Personally all my data & archive files are NTFS-W7 (which differs from previous versions of NTFS). Linux, which I use for most functions, most times, uses EXT4 partitions, but creates many incompatibilities with NTFS-W7: non-MS file names, multiple same-name files & seemingly rare & random write errors onto compressed NTFS-W7 partitions.
Compression, presumably, would've forced more changes than T'so liked, and encryption is handled by a lower level system (in the nix tradition of "small" programs doing "small" tasks) that any fs (saving btrfs, at least) can take advantage of.
Comment
Comment