Originally posted by benmoran
View Post
Announcement
Collapse
No announcement yet.
Facebook To Trial Btrfs Deployments
Collapse
X
-
Originally posted by kernelOfTruth View Postafaik got this also happening in the past - so this leaves this impression of btrfs randomly corrupting files on its own for me (of course could be wrong since it also detected a harddrive/partition that is on the verge of becoming broken - showing some more badblocks, internal errors); mentioned high memory usage (a memory leak ? on the mailing list), RAID handling when removing and re-adding a harddrive
Originally posted by kernelOfTruth View Postand of course this issue with ENOSPEC/free space fragmentation and/or non-reclaim of free space
Originally posted by kernelOfTruth View Postthis might be a side-effect of Btrfs' COW nature but at this late (?) point of development it slowly should be tackled and must not need an manual (especially advanced user) intervention to continue to be usable
if development continues like that it will again take years until the round edges are smoothened out
it has come a long way and improved a lot but there's still the feeling that fundamental mechanisms and parts are missing underneath
Luckily I also migrated all of my machines to lvm, so moving back to ext4 or tux3 should not be much of a problem.
Comment
-
Originally posted by kernelOfTruth View Postlocal copies ?
copies=3
lz4 compression ?
more advanced checksums than crc32c (e.g. sha256) ?
easy to use / user-friendly expert tools ?
trivial errors or "features" that are not showing during routine checks ? (e.g. the checksum missing for space_cache)
an inode_cache that doesn't take minutes to regenerate after having shut down the "links" browser and in the process slowing down the system to a crawl ?
actual NO slowing down during heavy i/o writes of the *entire* system compared to ext4 ? (on dm-crypt)
stability ? (already got corrupted files on /home; after a few crashes (hardlocks) the /home directory got that much messed up that the kernel would panic or couldn't access /home anymore)
these are all working features that are currently available on ZFSonLinux
this is not to badmouth Btrfs - rather a rant since I'm personally interested in a 2nd drop-in filesystem that could also be used on /home instead of ZFS (which doesn't support realtime kernels yet and suspend-to-disk, probably suspend-to-ram neither) - especially on the laptop to fully use energy-saving and time-saving features while maintaining maximum data integrity & -safety
If I remember correctly, the "copies=3" (or more) work is something that should show up after raid 5/6 scrubbing support is ready.
The lz4 compression seems to be really wanted by some, but I get the impression that not many people are interested enough to work on it. I don't use this kind of file system for space savings personally, so I am one of those that is happy with lzo.
I can't comment on the dm-crypt stuff, since I don't use it. Valid complaint though, as it seems like built-in encryption is not being considered.
Af far as stability and corruption, I've only had issues once with the known balance bug on a recent kernel. I've personally used btrfs on many machines at home and in the lab, some of which are hard reset many many times. I've not had any corruption in a dozen file systems. I know people have issues, but with recent code I consider it quite stable.
Some valid points, but I don't think it's fair to say it will take years to catch up to ZFS' features - because some are not planned to be included at all.
Comment
-
Originally posted by JX8p View PostWhat do you mean by 'volume management'? ZFS has datasets which are similar to 'volumes' but far, far more flexible, as well as ZVols, which are exactly as they sound like: volumes.
Comment
-
There are things people always don't know or forgot to mention.
I believe Suse disables the multi-device support in btrfs in their kernels.
They say, the general filesystem is stable, it's the multi-device support that they don't support yet.
Comment
-
Originally posted by kernelOfTruth View Postmore advanced checksums than crc32c (e.g. sha256) ?
Comment
-
Originally posted by ssam View PostIs that really needed. With a 32bit checksum, there is only a 1 in a billion chance that a corrupt block will go undetected. That sounds good enough for me. More advanced checksums only required if you are trying to defend against deliberate tampering, but if someone has access to tamper with the data on your disk, then they can also update the checksum. If the 1 in a billion is not enough for you then crc64 should be enough and will be much faster than sha.
And certain CPUs have SSE4.2 support, which has crc32c support as well.
Comment
Comment