Re: BUG _llseek kernel 2.4.17

[Matti Aarnio <matti.aarnio@zmailer.org>]

On Fri, Mar 01, 2002 at 03:03:27AM -0500, Tim Peeler wrote:
> There is a bug in _llseek (at least that's where I believe it to be)
   Nope.

> in kernel 2.4.17.   I'm using ext3 on an ia32 system.  While pondering
> max file sizes allowed on an ext3 system, I used 'dd' to create a
> fairly large file (8 gigs).  I decided to append to it, so I ran another
> dd to add another 200 megs to it. In telling dd where to seek to before
> appending to the file, i inadvertantly added an extra 0 telling it to
> seek to about 80 _Gigs_, not 8:

   Yes ?  Ever heard of sparse files ?
That is, space is never allocated for the intermediate data blocks,
nor to most of the intermediate metadata indices.

When read, those intermediate blocks will always show blocks filled
with zeros, but as long as you don't actually write them, they won't
consume space.

> I didn't notice what had happended until I checked the size of the file,
> and saw that it was 80 Gigs.   Since my disk is only 9 Gigs, this threw
> me off.  I tried dd several more times including:

  Sure, I have done maximum-file-offset testing on a 200 MB partition,
no problem at all.  (Seek to curpos + 1M, write a few bytes, repeat)
What "du -ak " reported on the file was few hundred kilobytes.  It gives
space consumed by the user data, and the metadata for the indices.

...
> After this careful consideration of the problem in question and
> the apparent area of failure, it seems that fstat is doing its job
> right, just that _llseek setting the position is the culprit.

  Nope.

> Tim

/Matti Aarnio