On 5/22/17 9:25 AM, Gionatan Danti wrote: > Hi all, I have a question regarding how to automatically shutdown (or > put in read-only mode) an XFS filesystem which reside on a full thin > pool. > > Background info: when a thin pool become full, it will deny any new > unallocated writes, but will continue to allow writes to > already-allocated storage chunks. So, it behave as a badly damaged > disk, where some places can be written, but others throw an error. > > Playing with dmsetup table it is possible to deny *all* I/O to the > volume, but it require careful monitor and a sensible script to do > the right thing (tm). > > From my testing, it happear that XFS will shutdown itself when a > metadata write fails, however, failed *data* update will continue > without triggering any filesystem response. Is this by design? Can I > do something about that? It is pretty much by design - keeping in mind that XFS predates the general notion of thin storage by a decade or two. ;) In the big picture, xfs's shutdown behavior is there to preserve the consistency of the filesystem - if metadata writes are failing, continuing would likely lead to corruption. If /data/ writes are failing, that's for the application to deal with. Shutting down the filesystem for an unwritable data block is probably not what people want to see, in general. > As a side note, I perfectly understand that async writes should *not* > put the filesystem in suspended state; however, I found this behavior > for synchronized writes also. I would expect that synchronous writes and/or things like fsync calls would return errors if the underlying data IO fails. As for your question about ENOSPC vs EIO, even though the storage may return ENOSPC, I believe that gets turned into an EIO when it passes through XFS to userspace. Historically, ENOSPC meant that the filesystem itself has run out of blocks, and EIO meant that the underlying device could not complete the IO - so it's a matter of semantics, and I'm not sure anyone has really settled on a consistent story with thin devices. -Eric > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
