Re: Quota file format [2.3 issue]
Mikko Hyvarinen (mikko.hyvarinen@geracap.com)
Tue, 13 Apr 1999 15:11:08 +0300
Jakub Jelinek wrote:
> 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.).
> Sparc64 solves this by doing userland format translation in quota utilities,
> but that means it is not even possible to exchange quota enabled disks
> between 32bit and 64bit SPARC boxes.
> Now, what do you think about starting to use a new quota.user/quota.group
> format in 2.3, which will be both endian independent and will use 64bit
> values for timestamps in it (ie. change similar to old/new swap style)?
> It would probably not need many kernel changes in dquot.c.
> 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.
>
> Comments?
Adding a 10 byte header will cause all subsequent 64bit values to be
misaligned unless necessary padding is inserted between the values or
the file is read to a buffer that is aligned so that the 64bit data
entries align properly. Anyway, screwing this up can (will?) cause
performance problems on 64bit architectures.
I would think a better way to solve this is to look for an impossible
value combination of the first (couple of) 32/64bit entries and use that
as a magic marker for the new format. Using a text-based format is
probably out of the question for performance reasons.
-Mikko Hyvarinen
-
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/