Messages in this thread | | | Date | Tue, 13 Apr 1999 23:33:36 +0200 | From | Jan Kara <> | Subject | Re: 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/
| |