On Mon, 27 Apr 2020 13:29:47 +0200 Marc Lehmann <schmorp@xxxxxxxxxx> wrote: > On Sun, Apr 26, 2020 at 11:25:47AM +0100, Hugo Mills <hugo@xxxxxxxxxxxxx> 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
