On Tue 30-03-10 09:26:52, Dmitry Monakhov wrote: > Jan Kara <jack@xxxxxxx> writes: > > On Fri 26-03-10 09:38:56, tytso@xxxxxxx 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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
