[linux-lvm] Snapshot behavior on classic LVM vs ThinLVM
g.danti at assyoma.it
Wed Apr 26 08:10:24 UTC 2017
Il 26-04-2017 09:42 Zdenek Kabelac ha scritto:
> At this moment it's not possible.
> I do have some plans/idea how to workaround this in user-space but
> it's non-trivial - especially on recovery path.
> It would be possible to 'reroute' thin to dm-delay and then write path
> to error and read path leave as is - but it's adding many new states
> to handle,
> to ATM it's in queue...
Good to know. Thank you.
> Using 'ext4' with remount-ro is fairly easy to setup and get exactly
I'm not sure this is sufficient. In my testing, ext4 will *not*
remount-ro on any error, rather only on erroneous metadata updates. For
example, on a thinpool with "--errorwhenfull y", trying to overcommit
data with a simple "dd if=/dev/zero of=/mnt/thinvol bs=1M count=1024
oflag=sync" will cause I/O errors (as shown by dmesg), but the
filesystem is *not* immediately remounted read-only. Rather, after some
time, a failed journal update will remount it read-only.
XFS should behave similarly, with the exception that it will shutdown
the entire filesystem (ie: not even reads are allowed) when metadata
errors are detected (see note n.1).
The problem is that, as filesystem often writes its own metadata to
already-allocated disk space, the out-of-space condition (and relative
filesystem shutdown) will take some time to be recognized.
From RED HAT STORAGE ADMINISTRATION GUIDE
Metadata error behavior
The ext3/4 file system has configurable behavior when metadata errors
are encountered, with the default being to simply continue. When XFS
encounters a metadata error that is not recoverable it will shut down
the file system and return a EFSCORRUPTED error. The system logs will
contain details of the error enountered and will recommend running
xfs_repair if necessary.
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8
More information about the linux-lvm