On 2015-05-18 05:22, Roy Sigurd Karlsbakk wrote:
>>> 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?
>
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).
>>> 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…
>
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.