On Thu, May 07, 2026 at 06:52:58PM +0100, Joe wrote: > On Thu, 7 May 2026 18:51:25 +0200 > <[email protected]> wrote: > > > On Thu, May 07, 2026 at 11:53:59AM -0400, Stefan Monnier wrote: > > > > [...] > > > > > > My point was that LVM actively asks mounted filesystems on LVs > > > > that are snapshotted to bring themselves to a consistent (clean) > > > > state before it does the snapshot. That was (20 year old) news to > > > > me. > > > > Is there any reference for that? AFAIK LVM doesn't "know" about the > > underlying file system (if there is any). > > > > > My guess is it would run 'sync' once or twice before beginning a > snapshot, or maybe some more sophisticated equivalent. I think we'd know > by now if it didn't.
This sounds very hypothetical: how should LVM that there is a file system /at all/ on the logical volume being snapshotted? How that this file system is mounted? Note that the snapshot would also secure the journal along, so the file system is pretty safe. Unless the journal is on another device... > Applications intended for servers really ought to be designed to be > ready for disaster at any time, and try to minimise inconsistencies. > Any database being used for an important purpose should be using > atomic transactions as far as possible, for example. But they are totally helpless if the backing store is munged in totally unexpected ways: if you just copy the PostgreSQL backing store /without/ taking with it the write-ahead log, you aren't going to have much fun. Cheers -- t
signature.asc
Description: PGP signature
