[Discuss] File systems that support file cloning

[Dale R. Worley]

> From: Rich Pieri <richard.pieri at gmail.com>
>> I tried out btrfs, and it has some management problems.  "df" doesn't
>> report free space correctly.  And apparently there is a need to run a
>> "rebalancing" program occasionally to keep free space accessible.
>
> Every file system requires periodic maintenance. Scrubbing and
> balancing is part of Btrfs maintenance.

Uh, yes.  I've never noticed ext2, ext3, or ext4 as needing periodic
maintenance.  Of course, I've never used disks in a
performance-demanding environment.  Or rather, the only demanding factor
was using a filesystem at very near completely full.

> Due to how Unix and Linux file systems work, no df is 100% accurate.
> Or, more correctly, df does not report *file* usage; it reports *file
> system* usage. The output from du and df will almost never perfectly
> align, and guaranteed not to align for root vs non-root users due to
> overhead reservation.

Yes, that's correct.  But on other file systems, if I delete a file
that's a large fraction of the disk space, I see df increase by about
the size of the file at that time.  The few tests I ran with btrfs, the
freed space nowhere near showed up in df, at least, not in the short
run.

>> Also, later when I was researching xfs, there were comments
>> suggesting that though btrfs had been around for many years, it was
>> still not fully reliable and people had seen filesystem crashes that
>> left the partition readable.
>
> That's FUD. Any crash can potentially damage any file system. Btrfs is
> no more or less potentially vulnerable than any other file system.

True, it's FUD.  Certainly, it's about fear.  But I've been using ext
filesystems since about Slackware 3.  ext2 would always need fsck'ing
when the system crashed, but I never lost any significant part of a file
system.  ext3 and ext4 have always survived without even needing
fsck'ing.  More relevant is that I've been heavily using xfs at work for
the past 5 years, and crashes never damaged it either.  If people
actually experience btrfs failing over a period of a few years, that's
noticeably worse.

>> I checked into zfs.  zfs has an integral volume manager.  I don't need
>> that, as I use LVM.  But unfortunately zfs's volume manager can't be
>> ignored by default.  So zfs has additional management overhead, like
>> btrfs.
>
> No, it doesn't. It just looks that way when you frame it in the context
> of traditional file systems and volumes. To wit: a data set is not a
> volume. It is a logical collection (a set) of data within a directory
> hierarchy. Where a volume is fixed size, the data in a data set can
> grow to fill the entire zpool, though you can limit this with quotas.

I wasn't exact enough.  I meant to say "has additional management
overhead *in my brain*".  I now "frame it in the context of traditional
file systems and volumes" and keeping it that way is the least trouble,
or at least, the least work.

Dale