Is there a file system out there that supports custom file size limit?

Question

I'm aware that EXT4 has a max_dir_size_kb mount option to set up the max size of each directory. It doesn't have a similar option to specify the max size of individual files, though. Is somebody aware of another file system that could do this ? I checked XFS, ZFS and ReiserFS, but didn't find anything, though I'm no expert on those file systems.

To be more specific about what I try to achieve : I'd like to limit the size of individual files that can be stored on a Samba share (individual files, not global quota, e.g. prevent users from storing files exceeding a given size). Samba doesn't have an option for this, and the Linux /etc/security/limits.conf doesn't work either with Samba (see https://askubuntu.com/questions/1315369/is-obey-pam-restrictions-still-supposed-to-work-in-samba-4-ubuntu-20-04, and the answer : the Samba developers explained that file size limits set up in /etc/security/limits.conf are not enforced).

So my idea was to define that limit on the file system level, but it doesn't appear there is a file system supporting this feature.

Answer 1

With Lustre 2.12 and later it is possible to specify a maximum file size limit on a per-file, per-directory, or per-filesystem basis by specifying a PFL layout that has a fixed-size component end and no "to the maximum file size" component, for example:

   $ lfs setstripe -E 1G -c 1 /path/to/<file|directory>

Files created under directory would be limited to 1GiB in size (e.g. in a log directory), and if directory is the root directory it applies to all new files in the filesystem, unless otherwise specified. That said, you probably don't want to set up Lustre for your use, unless your Samba server needs a lot of capacity/performance scaling.

It also wouldn't be very hard to add such a limit to ext4. It already has to deal with different maxbytes values depending on whether the file is block mapped (old style, 4TB limit) or extent mapped (new style, 16TB limit). Setting the s_maxbytes and s_bitmap_maxbytes values via a /sys/fs/ext4/<dev>/maxbytes parameter would be pretty straight forward and likely to be accepted upstream (you could patch your server kernel in the meantime).

The only tricky part is that the sysfs value should be used as the lower limit vs. the existing limits. It should not be possible to set maxbytes higher than the existing limits. Some code would be needed in the sysfs handler to reset s_maxbytes and/or s_bitmap_maxbytes to the old limits if the maxbytes parameter is set higher. It would be easier to code if s_sysfs_maxbytes was stored as a separate parameter in the superblock, but then it would need to be checked on each use, which is a bit slower, and it is very unlikely that these values would change at runtime. It would also need to replace all s_*_maxbytes accesses in the code with a helper, like:

loff_t ext4_inode_get_maxbytes(struct inode *inode)
{
        loff_t maxbytes;

        if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
                maxbytes = inode->i_sb->s_maxbytes;
        else
                maxbytes = EXT4_SB(inode->i_sb)->s_bitmap_maxbytes;

        if (maxbytes > EXT4_SB(inode->i_sb)->s_sysfs_maxbytes)
                maxbytes = EXT4_SB(inode->i_sb)->s_sysfs_maxbytes;

        return maxbytes;
}

Even with relatively basic coding skills this could be done by a kernel newbie, with mostly search-cut-and-replace.