Re: Advice on using BTRFS for vicep partitions on Linux

On 3/22/2023 9:34 AM, Ciprian Craciun ([email protected]) wrote:
> On Wed, Mar 22, 2023 at 10:30 AM <[email protected]> wrote:
>> OpenAFS implements its own CoW and using CoW below that again has no benefits and disturbs the fileservers "free-space" assumptions. It knows when it makes in-place updates and does not expect to run out of space in that situation.
> At what level does OpenAFS implement CoW?  Is it implemented at
> whole-file-level, i.e. changing a file that is part of a replicated /
> backup volume it will copy the entire file, or is it implemented at
> some range or smaller granularity level (i.e. it will change only that
> range, but share the rest)?
OpenAFS performs CoW on whole files within a Volume on the first update 
after a
Volume clone is created.  The clone can be a ROVOL, BACKVOL or untyped 
clone.

OpenAFS CoW is limited to sharing a vnode between multiple Volume instances.
Once a vnode can no longer be shared between two or more Volumes, the vnode
is copied.

OpenAFS does not perform CoW at a byte range level.

On Linux btrfs and xfs both support CoW at the block level.   A one byte 
change to
a 1GB file on btrfs will result in one block being copied and 
modified.   Whereas
OpenAFS will copy the entire 1GB.

>>> Unfortunately (at least for my use-case) losing the checksumming and
>>> compression is a no-go, because these were exactly the features that
>>> made BTRFS appealing versus Ext4.
>> If you say so...
>> AFS does its own data checksumming.
>>
OpenAFS does not maintain checksums.  Checksums are neither transmitted in
the RXAFS_FetchData and RXAFS_StoreData RPCs messages nor are checksums
stored and compared when reading and writing to the vice partition.
> Granted, RAID is not a backup solution, but it should instead protect
> one from faulty hardware.  Which is exactly what it doesn't do 100%,
> because if one of the drive in the array returns corrupted data, the
> RAID system can't say which one is it (based purely on the returned
> data).  Granted, disks don't just return random data without any other
> failure or symptom.
Bit flips occur more frequently than we would like which was the 
rationale behind
adding checksums and multiple copies and self-healing to ZFS.
> With regard to file-system scrubbing, to my knowledge, only those that
> actually have checksumming can do this, which currently is either
> BTRFS or ZFS.
There are some other examples but these are the only two regularly 
available as
a local Linux filesystem.

Jeffrey Altman