Re: [Yaffs] Quota support in YAFFS

On Wednesday 05 May 2010 01:57:11 Wookey wrote:
> +++ Charles Manning [2010-03-03 12:20 +1300]:
> > On Wednesday 03 March 2010 07:39:53 Wookey wrote:
> > > So far as I can tell YAFFS doesn't support unix user quotas.
> >
> > Correct, there is no quota support.
> >
> > > Would it be hard to add? We'd like to be able to allocate users a
> > > limited size of flash they can use for user docs and I think quotas
> > > would allow this, but YAFFS doesn't have any so that's not going to
> > > work as-is.
> > >
> > > Can anyone confirm that my understanding of qhat quotas actually do is
> > > correct, and any idea how much work it is to add, or if there are
> > > reasons why it isn't going to fly?
> >
> > Well, like any software, it's just ones and zeros so it **could** fly
> > with sufficient will. How much effort is required I don't know as this
> > would need some reading up on how quotas work.
>
> Our rather uninformed persuing suggests that one just needs to turn on
> quota support in the kernel VFS and then link to the quota header
> instead of noquota.h and make sure that functions in your filesystem
> callback the relvant 'update' functions to keep track of quota counts.

Yes the interfacing is simple. The devil is in the details... the lazy loading
etc...

>
> And apparently some android people have already got this working, so
> it's probably not too hard.

URL?

>
> > There are two ways to manage quotas: per user and per group. Full
> > user/group support needs knowledge of how much space is used by each
> > user/group. That info is available once file details have been loaded,
> > but not directly at mount. After a lazy-loaded mount we know what file
> > sizes are, but don't know their group/user.
>
> Hmm, that sounds like it might be a problem. We'd have to stop doing
> lazy-loading in order to support quotas? Or could checkpointing save
> the current user/group counts so we can just track it for each file
> changed?

The checkpt could be expanded to include user/group quite painlessly.

We could push the info into tags but (1) don't want to fiddle with tags (2)
don't want to make them bigger.

The issue is in scanning with lazy-loading. ... That forces scanning to read
the whole object header.

Now that we have a background thread we could bring the fs up with no quota
then use load up the quota info later? eg. after a few seconds.

Something I want to do sometime (this year) is adding block summaries to speed
scanning. There is enough space in a 2k page to hold the tags + user/group
data for a block. That would make scanning way faster than it is now and also
get user/group up too.

>
> > If your intentions are to just reserve some space for root then there
> > might be some much easier ways to do things.
>
> Well the idea is to limit user data size so that the system doesn't
> fill up. Having started writing code to keep track ourselves in the
> app it's starting to look like it would be smnarter to have the
> filesystem do it for us. The app doesn't run as root (after startup).

Of course. It is always smarter when someone else does it :-).

I wonder whether it would be at all useful to find just one bit in the tags
structure to indicate "root" vs "other".