>> I recently realized the format of quota.user and quota.group is
>> both endian and archsize dependant. I think that's very wrong,
>> because when you have a nicely portable ext2 filesystem on some
>> disk and you want to move it to another computer, you loose if
>> you have quotas on it (in the best case quotaon will not succeed
>> and you won't have quotas on it, in the worst case it will
>> succeed and do strange things, you'll probably loose all your
>> quota information etc.).
>> One problem is quota.user is completely header-less and in its
>> whole size contains data which can have any value, so it is not
>> easy to distinguish old format from some new one. The only thing
>> which comes to my mind is file size: current kernel requires
>> quota.user (group) to be non-zero size and some multiple of
>> struct dqblk size. That's for sure divisible by 4. So what about
>> if we attach a 10 byte header before the whole data lot, which
>> will include some magic number and format version, so that's its
>> extensible and then follow it by lets say little endian
>> structures with 64bit times. That would mean the size of the
>> file is always some multiple of 4 plus 2, hence the kernel and
>> utilities can easily find out.
> I've also realized this problem when reading quota code. Also we
> should be aware of padding of the structure (currently I think
> there will never be any padding in the structure but...).
> I like the proposed solution and it would be easy to implement
> it... Because I'm currently making some fixes in quota code so I
> can add this feature too (It will be really only a few lines of
> code in the kernel...).
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.
Other than that point, comments, anybody?
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
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/