lkml.org 
[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Quota file format [2.3 issue]
  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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.070 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site