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. -- 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
