On 2015-05-18 05:22, Roy Sigurd Karlsbakk wrote:
While I don't know of any that use it by _default_ yet, I do know that it is an easy to use option on most of the big non-comercial distros already (Debian, Fedora, Ubuntu, etc.), and a couple (Gentoo, Arch, and possibly Slackware) have had the option to use it since it went mainline (although that is just a side effect of the installation procedures, not any kind of active attempt at support).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?
To me, this sounds like some sort of systemd issue, I have heard of it having issues occasionally with long delays when handling btrfs filesystems with more than 4 devices.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...heheLastly - 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…
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
