>> For btrfs to be accepted as a primary filesystem in major distros, I'd >> think it should integrate with existing tools. > > Well, fortunately or unfortunately, btrfs is already being accepted as a > primary fs in major distros. Interesting - which ones is it that's doing this? >> Currently, df seems to show good data, while du doesn't. > > There has been some work put into what df returns to make it so, while > similar work to du has not yet been released, and in fact only quite > recently (within the last month) has been proposed on the list. > > Maturity of the filesystem, again... hehe >> Lastly - I just did a small test on a 6 drive RAID-6, turned on >> compression and started cat /proc/zero > testfile - let this run until >> the filesize was 500GB and stopped it. Made some other test files and a >> copy of these with --reflink=auto just for kicks. rm test* and waited. >> While waiting, did a 'echo b > /proc/sysrq-trigger' and fsck started on >> bootup and took a minute or so to complete. Since the filesystem is >> rather small (6x8GB VDEVs on top of ZFS with SSD caching, kvm as >> hypervisor), I wonder how long this fsck job would take if it were on a >> system with, say, 6 4TB drives. RHEL/CentOS7 just moved to XFS to allow >> for system crashes without this hour-long fsck job, and I somewhat doubt >> that btrfs will be the chosen one if it requires the same amount of time >> as of ext4. > > As Qu mentions, on-mount fsck is not needed on btrfs, as assuming no bugs > (filesystem maturity, again), due to btrfs' COW nature, commits are > atomic and the filesystem is self-consistent at every commit. Commits > occur every 30 seconds by default (it's a mount option), and there's only > a very limited journal of fsynced transactions kept since the last > commit, to be sure they are recoverable even when the filesystem crashes > between commits, that automatically replays on mount. So no on-mount fsck > needed. I didn't run it. Some part of the Jessie startup did, and 1 minute for just 6x8GB (not TB) seems a lot… roy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
