> I have seen situations where alignment (and probably striping) were causing > issues. I don't have details available any more, but iirc, depending on how > you create file systems, the respective program can derive some information > about block positioning from underlying layers (i.e. lvm, where those in > turn can make use of information about the underlying block > storage). However, that's probably implying a certain storage complexity > where images restores would probably become tricky for other reasons, too.
Oh, yes, we had a thread here a while back about that (ext4 somehow cared about the block size of the underlying drive, IOW LVM did not fully hide the underlying hardware and ext4 uses that info. In my book that's a bug), but AFAIK this is independent from LVM snapshots: the same happens if you just unmount the filesystem, then `ddrescue` the original LVM volume to another LVM volume on a drive with a different block size. So I guess you're just saying that it's best not to backup filesystem images, but to backup the actual filesystem itself. I'd tend to agree. IOW the recommendation is: make an LVM snapshot, mount it, and backup that filesystem. > I'm sure I don't want to meet people who think it's reasonable to put, > for example, exFAT or f2fs into LVs, but I would still be careful to > consider the supported set of combinations. I've never used such filesystems in LVM, but again if they don't work correctly in such a setup, I'd count it as a bug. >> As for "application data consistency", yes, that's >> a more complicated question. > Indeed, and it's what many people prefer to ignore, although eventually it's > at least theoretically much easier solved. It all depends on the underlying layers providing sane semantics, of course. >> [ Just last week-end my desktop's power supply died while in the middle >> of a big set of `git pull` operations. Of course, after I replaced >> the power supply, the filesystem was perfectly "consistent" yet many >> of the new files ended up empty, including some in the `.git/objects` >> directory, leading to errors about missing blobs and whatnot. >> Not sure if that was a bug in Git or a misfeature of ext4's default >> journaling. ] > > Which probably led you do just do a new checkout? Not yet: I like to live on the edge, so I deleted the empty files and then went on to fix the immediate problems I bumped into: `git gc` still complains about that missing blob, but so far the rest works. Still looking for that missing blob (other Git clones of the same upstream repository don't have that missing blob and none of the existing worktree files correspond to it either). === Stefan
