Hi Khimenko.
>>> All three. VFS does not support them so you can not have files
>>> over 2GiB on 32bit proccessor with ANY filesystem though.
>> Are there any plans to implement 64-bit file sizes in VFS? What
>> are the problems - is it anything more than making a few fields
>> 64-bit quantities instead of 32-bit ones, and implementing a
>> couple of new system calls?
> And LOTS of testing :-) Of course just this. Reiser proposed to
> support files over 2GiB in 2.3.x with upcoming version of
> ReiserFS for 2.3.x ... When (and if) it'll be ready to actual
> use is not clear though. Of course you'll need updated version
> of glibc 2.1.x as well
All very true...
> (BTW what should happen with "old" system calls when they are
> used for big files?)...
My suggestion would be to use the following rule set:
1. Where a function accepts a 32-bit signed offset as a parameter,
it should just sign extend that offset to 64-bit internally and
use the resulting value. This can't cause any problems.
2. Where a function returns a 32-bit signed offset, either as a
parameter or as the return value of the function, and the value
to be returned fits therein, it should return the value in the
usual way. This applies irrespective of the actual size of the
file in question.
3. THE PROBLEM CASE: Where a function returns a 32-bit signed offset,
either as a parameter or as the return value of the function, and
the value to be returned does not fit therein, what happens?
One thing to note is that in many programs, the actual value
returned is never used, and we should not break those programs
with whatever behaviour we choose. I would therefore suggest that
the correct response would be to return -1 and set errno to
ETOOBIG (or whatever it's called), and expect the program to
respond to that with...
signed u64 posn;
posn = lseek(fp,0,SEEK_CUR);
if (posn == -1 && errno == ETOOBIG)
posn = llseek(fp,0,SEEK_CUR);
...or the like.
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| 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. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:14 EST