Skip to contentSkip to conversation

Quota mods needed for journaled quota

DISCUSSION Jan Kara 1 participant 2 messages Oct 31, 2000 1 message not in the archive

lore
Share & tools
lore

Jan Kara

author
#1 lore raw
In reply to a message not in the archive

Hello.

Quoted 6 lines

There are a few problems in the Linux quota code which make it impossible to perform quota updates transactionally when using a journaled filesystem.

Basically we have the following problems:

Quoted 7 lines

* The underlying filesystem does not know which files are the quota files, so cannot tell when to apply journaling consistency guarantees to data writes

* "chown" is not transactional: the filesystem is given no opportunity to wrap the quota transfer and the owner-attribute notify-change call into a single transaction.

In my quota fix this has changed a bit as now filesystem's notify_change()
is calling dquot_transfer() (it was needed due to some races and I think it's also more consistent with how other quota calls work). So this problem should exist no more.

Quoted 11 lines

All of these could be fixed very easily (at least for ext3) if it were possible for ext3 to install its own version of the superblock->dq_ops quota operations (which would just be simple wrappers around the existing quota calls). However, the current sys_quotactl installs the default quota_ops into the superblock on quota_on without any chance for the filesystem to override it.

The addition of an "init_quota" method to the super_operations struct, with quota_on calling this and defaulting to installing the default quota_ops if the method is NULL, ought to be sufficient to let ext3 get quotas right in all cases as far as I can see.

Actually I was proposing something similar in my reaction on dquot hang in
ext3... The only difference was that I proposed to install dq_ops in foo_read_super() so that it will be more consistent with how other callbacks work. And in my fix of quota I removed testing of dq_ops being NULL so operations can be set during all life (mount time) of filesystem.

Honza
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

author
#2 lore raw
In reply to a message not in the archive

Hello.

Quoted 19 lines · Stephen C. Tweedie
Quoted 11 lines

Subject: Re: Quota mods needed for journaled quota
...

Quoted 4 lines

This would allow ext3 to do that which it needs to do differently at Q_QUOTAON and would also allow Jan's changes to work in such a way that both the current form of dquot structure and his new version of dquots could be used together

Adding the init_quota hook would do that, as the filesystem will be able to install its own dq_ops methods during the init so we get the flexibility you are asking for anyway.

Hmmm ... I'm not so sure. In order to have the flexibility of filesystem-specific dquot formats, the struct dquot would need to become more like struct inode/super_block, i.e. not hardcoding the ondisk structure into the incore structure (using a union and a generic pointer, as inode/super_block do).

Quoted 6 lines

The DQUOT_SYNC mechanism would need to be able to be overridden per-filesystem also. It isn't really as cut-and-dried as "per- filesystem" either, because an ext2/3 filesystem might make use of either the original dquot format or Jan's newer format, either at mount time or even after doing a quota_off & quota_on with a new quota file format (that would be quite clean).

Hmm. Probably I wouldn't allow to override quotactl() but make it like
other callbacks - operations like quota_on() quota_off() and so could be overridden (or better filesystem could specify callback to be called after some generic work), quotactl() will call foo_quotactl() if it won't recognize the operation number.
But I don't feel urgent need of this redesign so I would wait for some
time so current fixes can settle down...

Honza

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/