Re: questoin about Data=single on multi-device fs

[Roman Mamedov <rm@romanrm.net>]

On Mon, 27 Apr 2020 13:29:47 +0200
Marc Lehmann <schmorp@schmorp.de> wrote:

> On Sun, Apr 26, 2020 at 11:25:47AM +0100, Hugo Mills <hugo@carfax.org.uk> wrote:
> > > The reason I chose data=single was specifically to help in case of device
> > > loss at the cost of performance.
> > 
> >    Make backups. That's the only way to be sure about this sort of thing.
> 
> I think you are unthinkingly repeating a wrong (and slightly dangerous)
> claim - backups cannot actually do that sort of thing: a raid will protect
> against (some amount of) disk failures with no data loss, but backups
> cannot: Backups can protect against complete data loss, but cannot
> completely protect against data loss.

With backups it is at least clear enough to anyone that only the data that has
been backed up will be recoverable from the backup;

On the other hand you follow a much more dangerous theory, that a low-level
JBOD-style merging of disks can be of any significant "help" in case of a
device failure. That's often heard applied to LVM LVs spanned across multiple
devices, or MD Linear, or in this case Btrfs "single". In all of those cases I
have to wonder how getting to keep a few chunks of what some time ago was a
filesystem, or in your case, *random pieces of random files* being luckily
intact, will be of any help and alleviate the need to restore from backups.

If you really want a JBOD-style storage merged into a single pool, with device
failures having impact limited only to that device, better look into FUSE
file-level overlay filesystems, such as MergerFS and MHDDFS. At least with
those you are guaranteed to have whole files intact on still running devices.
Exactly what Btrfs doesn't guarantee you now (seemingly even more so), but most
importantly never did, not even on any prior kernel version.

-- 
With respect,
Roman