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).
-Matt