On Mon, Jun 03, 2024 at 07:36:42PM +0800, JunChao Sun wrote: > Currently, FUSE in the kernel part does not support quotas. If users > want to implement quota functionality with FUSE, they can only achieve > this at the user level using the underlying file system features. > However, if the underlying file system, such as btrfs, does not > support UID/GID level quotas and only support subvolume level quota, > users will need to find alternative methods to implement quota > functionality. How would your quota shim find out about things like the increase in block usage of the underlying fs? Let's say the underlying fs is like vfat, which fakes sparse hole support by allocating and zeroing (as needed) all the space before the start of the write. So the kernel tells fuse to write a byte at 1MB. Most unixy filesystems will allocate a single block, write a byte (and the necessary zeroes) and bump quota by 1. fat instead will allocate 1028K of space, zero all of it, and write the byte. How does /that/ get communicated back to fuse? Some sort of protocol extension that says "Hey I wrote the data you asked, and btw block usage increased by XXXX bytes"? If that increase takes you over an enforced quota limit, the correct response would have been to return EDQUOT having not made any changes to the file. --D > And consider another scenario: implementing a FUSE file system on top > of an ext4 file system, but all writes to ext4 are done as a single > user (e.g., root). In this case, ext4's UID and GID quotas are not > applicable, and users need to find other ways to implement quotas for > users or groups. > > Given these challenges, I would like to inquire about the community's > perspective on implementing quota functionality at the FUSE kernel > part. Is it feasible to implement quota functionality in the FUSE > kernel module, allowing users to set quotas for FUSE just as they > would for ext4 (e.g., using commands like quotaon /mnt/fusefs or > quotaset /mnt/fusefs)? Would the community consider accepting patches > for this feature? > > I look forward to your insights on this matter. > > Thank you for your time and consideration. > > Best regards. >
