Thoughts on Quotas

Matthew Dillon dillon at
Sun Sep 26 10:06:50 PDT 2010

    Historically the quota subsystem had to be integrated into the
    filesystem (i.e. ufs) because only the filesystem knew the actual
    disk block usage for a file.   e.g. if one were to create a sparse
    file, only the actual blocks used would count towards the quota.

    I don't think this level of accounting is realistic any more these
    days, particularly when so many administrative tools like to scan
    whole files.  If someone were to create a 10TB 'sparse' file in
    HAMMER the administrative tools will tend to blow up.

    So my thinking w/ regards to a quota system is that it should no
    longer attempt to track actual block usage but instead should simply
    track aggregate inode and file size(s).  If a user wants to create
    a sparse file and quotas are enabled then that user must have
    sufficient quota for the file whether it is full of holes or not.

    Removing the actual block-counting requirement allows us to implement
    a generic quota system in the kernel, in kern/* instead of
    per-filesystem.  If someone were to take on the quota project that
    is how I would request it be done.


    W/ regards to HAMMER PFSs... the PFSs aren't designed for per-user
    operations.  I think it would be far easier to break the userbase into
    categories for historical retention purposes (and in most cases just
    having one /home would be sufficient).


More information about the Kernel mailing list