Re: Quota file format [2.3 issue]

Jan Kara (jack@atrey.karlin.mff.cuni.cz)
Tue, 13 Apr 1999 23:33:36 +0200


Hello.
>
> If we wish to make ANY changes to the quota file format, we need to
> define a NEW quota file with a new name, and get the file format
> correct to start with...
This would be probably the cleanest solution but I think the solution
proposed by Jakub should also work (at least from kernel point which I'm
aware of).

> >> Can I suggest the following header format for the quota file:
>
> >> Q> struct quota_header {
> >> Q> char id[5];
> >> Q> unsigned char vsn;
> >> Q> unsigned short endian;
> >> Q> };
> >> Q>
> >> Q> struct quota_header qh = { "QUOTA", 0, 0x1234 };
>
> > Such a header is a valid old format quota.user as well, 2.2.0
> > kernel would happily assume it is the old format and do bad
> > things with that.
Maybe I'm missing something but I can't find anything about older format
of quota in current kernel. There is only one struct dqblk...

> > I was trying to explain that the only way I'm aware of how to
> > force old kernel not to touch new format file is to make its
> > size not be divisible by sizeof(struct dqblk).
>
> Are you sure that strategy will work? I would expect it to result in
> both old kernels and the old quota tools happily reading records that
> consist of the end of one record and the start of the next, and really
> mangling the file as a result.
I'm not sure what will do quota utilities but kernel will refuse to read
such quota file.
> > Then kernel would have to swap it if it plays with other format
> > type, but not swap it if it is the same endian.
>
> Alternatively, and probably a much more sensible solution here, the
> quota enabling tools could refuse to enable quotas on that partition
> if the file is in the wrong endian format, and a separate tool could
> be provided that runs through the quota file and rewrites it in the
> correct endian format for that system.
This is much better solution. There we can have simplier kernel functions.
> > On the other side, doing cpu_to_le32() does not hurt anybody,
> > especially on quota code.
>
> Does the existing quota code do that? If not, then the situation still
> needs to be dealt with...
No. Current code just reads data as they are. This is why the thread begun ;-).

Bye Honza.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/