On Wed 11 Oct 2023 at 22:55:03 (-0400), Jeffrey Walton wrote: > On Wed, Oct 11, 2023 at 10:49 PM Andy Smith <a...@strugglers.net> wrote: > > On Wed, Oct 11, 2023 at 04:25:58PM -0500, Mark Copper wrote: > > > suddenly, all files created on /dev/sda1 for the last 27 days have > > > disappeared, even files I edited this morning before restarting. Like the > > > clock was turned back a month. The disk, a new 18 TB, passed the test > > > > This happened to a customer of mine once, and they asked me to look > > into it. When I did I found that: > > > > - they were using LVM > > - they'd taken a snapshot of their root fs > > - they were finding and mounting their root fs by fs UUID > > - snapshot obviously had same fs UUID > > - the kernel was finding the snapshot first at boot > > > > Could anything like that be happening? > > That's devious. > > I can't help but wonder how many hundreds or thousands of man hours > were wasted because LVM was not designed to avoid the problem by > default.
It's not clear to me what's meant in this thread by snapshot. If you mean snapshot in the way it's been used in several recent threads here (something that takes up no room to start with, but gradually grows as the filesystem is modified, ie Copy-On-Write), then I don't see how you can mount such an object on rebooting. Is that possible? If you mean snapshot as a full copy of a filesystem at a point in time (like 27 days ago), then step N+1 is to either remove the copy from the system (a backup is of dubious value when stored in the same machine), or change it's LABEL/UUID/…, or both. That change is just as essential whether the copy was created by means of a "snapshot" or just a simple dd. Cheers, David.
