[lkml]   [1999]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Quota file format [2.3 issue]
> 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 };
> This should occupy exactly eight bytes, and deal with all of the
> problems mentioned. It has the following properties:
> 1. A 'magic number' that identifies the file format and can be
> added to the database for the `file` program. This can also
> be used to determine whether the quota file has the header
> present or not.
> 2. A 'version number' that can be incremented to specify changes
> to the format of the quota file.
> 3. A multi-byte word with known value that can be used to decide
> whether values in the quota file are stored in little-endian
> or big-endian format. The code can then adjust itself to deal
> with whatever is found.
> OK, the use of "unsigned char" to specify an 8-bit field, and the use
> of "unsigned short" to specify a 16-bit field is probably not what
> Linux uses, but that can easily be changed to use whatever names Linux
> uses for suchlike fields.

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.
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). On the other side, it does not make much sense to me
to have the file format in both endian versions. Then kernel would have to
swap it if it plays with other format type, but not swap it if it is the
same endian. Look at UFS code how it sucks because UFS is both little and
big endian. On the other side, doing cpu_to_le32() does not hurt anybody,
especially on quota code.
So I'd more think in terms of

quota_header: id 8 bytes (some magic number)
version 2 bytes

and after it n times
bhard 4 bytes
bsoft 4 bytes
bcur 4 bytes
ihard 4 bytes
isoft 4 bytes
icur 4 bytes
btime 8 bytes
itime 8 bytes

as it is always read by read(2) or written by write(2), it does not matter
much that the structures in the file are not aligned on 8 bytes boundary.

Jakub Jelinek | |
Administrator of SunSITE Czech Republic, MFF, Charles University
UltraLinux | |
Linux version 2.2.5 on a sparc64 machine (3958.37 BogoMips)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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