Messages in this thread | | | Date | Tue, 13 Apr 1999 15:11:08 +0300 | From | Mikko Hyvarinen <> | Subject | Re: Quota file format [2.3 issue] |
| |
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/
| |