Hi, I wonder if this is a useful idea. Some thinly provisioned devices lie about how many blocks they have on a LUN. Eg, they claim to have 16TiB, but really have much less, depending on the actual disks they have or the amount of space that administratively backs the device. This creates problems for users and the underlying file systems when the user inadvertently tries to use more space than is available. Writes start failing (probably journal writes), devices go off-line and file systems get mounted read-only, and even after a reboot, there might be problems replaying the log, leaving the user with an unmountable file system or whatever. Ext3/4 has a routine in balloc, ext3/4_has_free_blocks, which checks to see if there are free blocks. It currently knows about the root reserve, and if the user does not have CAP_SYS_RESOURCE and the request would take us below the root reserve, the request is denied. It would seem easy to extend this to a lying reserve, lying_reserve, that is initially set to zero, and which is exposed via /sys/some/path, where the value checked is root_reserve + lying_reserve, or something like that (the details are yet to be worked out, because of delayed block group allocations etc), and if the request would take us below that amount, deny the request for blocks. A userland daemon would be responsible for calculating the correct lying_reserve and telling the file system. This would prevent users from exhausting all blocks on a thinly provisioned device by failing writes in the file system rather than failing them in the SCSI layer or ATA layer and having the errors trickle up to the FS ... If this has already been though of, or is crap, just ignore me. -- Regards, Richard Sharpe -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
