Messages in this thread | | | From | Neil Brown <> | Date | Mon, 7 Aug 2000 12:15:29 +1000 (EST) | Subject | Re: New entry in inode/stat |
| |
On Monday August 7, jack@suse.cz wrote: > > > > i_size is now 2 giga but i_blocks is still zero if the fs support holes. > Thanks Andrea for replies. > > Yes. i_size has problem that it doesn't show real disk usage and so > is unusable for quotas... i_blocks is what quota needs but reiserfs > has smaller objects than 512 bytes and if we accounted any single object > as 512 bytes it would be too imprecise (some objects are around 40 bytes > or so). So I see no other way than adding another field. If anybody > sees other reasonable solution I will gladly use it... > > Bye > Honza >
Well.... it depends on what you mean by "reasonable" but..
It is (should be) entirely appropriate for a filesystem to do all disc-usage calculations internally. It just registers it's own "struct dquot_operations" in sb->qd_op at read_super time. Then you could account any way that you like, and just provide numbers in the appropriate units to the quotactl syscall.
Looking at the code though, I'm not at all sure it is as easy as it should be, as "struct dquot" only stores blocks, not bytes, and so your filesystem would have to duplicate all the "struct dquot" management.
What I would probably do: Assert that "struct dquot" stored bytes. As sb->s_quotasize to the superblock which defaults to sb->s_blocksize Change DQUOT_ALLOC_BLOCK et.al to mutiply "nr" by sb->s_quotasize instead of sb->s_blocksize, and not to divide by BLOCK_SIZE (done by fs_to_dq_blocks in quota.h) Add new operations to dquot_operations to read/write the quota file. change sys_quotactl to convert between bytes (as stored in struct dquot) and blocks are reported to use-space.
Then reiserfs can register it's own dquot_operations that includes read/write operations which stores bytecounts in the quota file, and it can set s_quotasize to '1' and can pass byte counts to DQUOT_ALLOC_BLOCK.
I feel that I have probably missed something significant here, but I think you get the idea.
NeilBrown
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |