Darrick J. Wong <djwong@xxxxxxxxxx> 于2024年6月6日周四 23:17写道： > > 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. It turns out that's actually the case, and the previous 1024KB of empty space cannot be reused. I tested by creating a 10GB vfat filesystem, created 9 files, and wrote a byte at the 1GB-4KB position in each file. When I tried to do the same operation on the 10th file, I encountered an ENOSPC error. I find this extension a bit peculiar because the user has spent a lot of time to get data written to the disk and the write has been completed correctly, but Fuse informs the user that the write has failed and is invalid... It's likely to get users confused. Furthermore, users would need knowledge of the underlying filesystem to accurately report how many bytes the disk usage has increased. Perhaps it's better to accept that a fuse fs based on vfat cannot support quotas, and indeed, vfat currently does not support quotas. However, it's necessary to carefully consider how to make it so that users do not use quotas on a Fuse filesystem based on vfat... > > --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. > > Best regards, -- Junchao Sun <sunjunchao2870@xxxxxxxxx>
