lkml.org 
[lkml]   [1999]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Quota file format [2.3 issue]
  Hello.
>
> 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.).
[snip]
> 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...).

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/

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