[linux-lvm] Snapshot behavior on classic LVM vs ThinLVM

[Gionatan Danti]

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 
> this
> logic.

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.

Note n.1
 From RED HAT STORAGE ADMINISTRATION GUIDE 
(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch06s09.html#idp17392328):

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.


-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8