On Wed, Nov 17, 2021 at 12:07 AM Gabriel Krisman Bertazi <krisman@xxxxxxxxxxxxx> wrote: > > FS_ERROR is a fsnotify event type used by monitoring tools to detect > conditions that might require intervention from a recovery tool or from > sysadmins. This patch series enables tmpfs to report an event when an > operation fails because the file system is full. > > It attempts to only report events when the filesystem is really full, > instead of errors caused by memory pressure. The first patch prepares > the terrain by detecting these two different conditions, and the second > patch actually adds the event triggers. > Hi Gabriel, Two things bother me about this proposal. One is that it makes more sense IMO to report ENOSPC events from vfs code. Why should the requirement to monitor ENOSPC conditions be specific to tmpfs? Especially, as I mentioned, there are already wrappers in place to report writeback errors on an inode (mapping_set_error), where the fsnotify hook can fit nicely. I understand that you wanted to differentiate errors caused by memory pressure, but I don't understand why it makes sense for a filesystem monitor to get a different feedback than the writing application. The second thing that bothers me is that I think the ENOSPC condition should not be reported on the same event mask as filesystem corruption condition because it seems like a valid use case for filesystem monitor to want to be notified about corruption and not about ENOSPC. Therefore, I suggested using the event flag FS_WB_ERROR for writeback errors. Other than the event mask, everything else is the same. It just provides the UAPI flexibility to subscribe to one without the other. Thanks, Amir.
