On Mon 21-09-15 12:35:01, Dongsheng Yang wrote: > On 09/18/2015 07:20 PM, Jan Kara wrote: > >>.... TBH, there is a little different with other filesystems. I did not > >>use the "disk" space, but the file space in ubifs quota, although dquot > >>means disk quota. Same with btrfs quota. If we use disk space for quota, > >>the most common problem from user is that: why I did not reach the limit > >>but I can not write any byte. COW in btrfs or out-place-updating in > >>ubifs makes this problem much worse. > >> > >>So I choose file space here for ubifs. > > > >OK, so these are really two separate questions. I understand your choice of > >using file space as the amount of space to account for quota purposes and > >I'm fine with that choice. Another thing is that regardless of how you > >decide to do quota accounting, you must maintain i_blocks / i_bytes to > >contain proper value because dquot_transfer() uses that information to update > >quota usage when inode owner is changed. > > But if we don't use i_blocks to get qsize, what we care only in > dquot_transter() is dquot->dq_dqb. That means, even if the i_blocks > is not correct in dquot_transfer() in ubifs, that's okey, because we > will never use this value, right? dquot_transfer() will use the value - when file F changes owner from user A to user B, then you need to decrement amount of space used by F from A's quota usage and add that amount to B's quota usage. And the amount of space is obtained via inode_get_bytes() which uses i_blocks and i_bytes. See __dquot_transfer() in fs/quota/dquot.c for details. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
