Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck

[Jan Kara <jack@suse.cz>]

On Tue 30-03-10 09:26:52, Dmitry Monakhov wrote:
> Jan Kara <jack@suse.cz> writes:
> > On Fri 26-03-10 09:38:56, tytso@mit.edu wrote:
> >> On Fri, Mar 26, 2010 at 11:42:05AM +0100, Jan Kara wrote:
> >> > > There may also be other programs that depend on the existence of
> >> > > aquota.user, and may be reading and writing them in various random
> >> > > ways, and there is the question of how do we provide compatibility
> >> > > with these other programs, some of which may not be within quotatools,
> >> > > but in various magic virtualization or container or cluster management
> >> > > systems....
> >> >   Yeah, this is possible, although I'm not aware of any such program -
> >> 
> >> Actually, Google's cluster management system is accessing/modifying
> >> aquota.group file directly before and after quota is enabled.  This
> >> may change in the future, but it's one more point of compatibility.
> >   I see. Thanks for info.
> >
> >> >   Yeah, I believe that support for the oldest quota format can be phased
> >> > out - the new format is around for something like 10 years and it had
> >> > it's problems at that time already. I guess I'll add a warning to the
> >> > next release of quota-tools to the people still using it.
> >> 
> >> And if we transition to using quotactl calls to access and read the
> >> information in the quota files, then the actual format of the quota
> >> file won't matter any more, right?
> >   Yes, hopefully.
> >
> >> Stupid question --- how does repquota work on OCFS2?  I don't see any
> >> quotactl subcommands that would appear to return the functionality
> >> needed by repquota --- unless you just assume that the only uid/gid's
> >> in use are in /etc/passwd and /etc/group, and just call quotactl for
> >> each uid/gid in the system passwd and group files.
> >   Currently it does not work at all. I didn't get to writing it when
> > writing original quota support for OCFS2 because the inferface won't be
> > completely trivial and it would be complicated for OCFS2 to expose the
> > file directly. Probably the interface will have to be something like
> > readdir but then you have to have some "handles" and state associated
> > with them and it gets complicated. Maybe we could make our life simpler
> > by returning an read-only unseekable fd from repquota quotactl and reading
> > from it would pass quota structures. But I haven't thought too much about
> > it.
> Ok. i hope finally we will end up with something like this.
> Before introducing this interface it is reasonable to redesign
> dquot structures itself because they aren't linked together
> so it is not easy to iterate it without probing each id in a loop.
  Well, the quotactl call would scan the quota file on disk anyway because
all the dquot structures needn't be loaded in memory. So linking structures
in memory will not help.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR