access beyond end of device?
Benjamin Scott
dragonhawk at iname.com
Wed Jul 13 02:22:00 EDT 2005
On Jul 12 at 11:35pm, Bill McGonigle wrote:
>> I'd be kinda surprised if that actually worked. I'm pretty sure there
>> would be metadata past the end of the device if the filesystem actually was
>> truncated.
>
> Where's it stored if the device ran out a few blocks ago?
That should be "there would have been metadata".
In other words, if I have my 3 TiB filesystem that sudden gets truncated at
90 GiB, all the filesystem metadata that was past 90 GiB is now gone, leaving
a gaping hole in the filesystem's internal data structures.
>> Given that the block being requested is way beyond the original size of the
>> filesystem, I think it's far more likely that some piece of metadata is
>> pointing into hyperspace, rather then the filesystem as a whole being
>> screwed up.
>
> Right, but that metadata must live within the bounds of the device if it's
> being seen by the filesystem driver in the first place. A resize _ought_ to
> redo those so they point to reachable locations.
I wouldn't expect a resize to do so because a resize expects to move both
user data and internal meta data out of the area that is to be truncated. If
said area is *already* truncated, then when it goes to move that data out of
there, it's going to have the same EOF problem the filesystem driver. I would
expect the resize to abort at that point. Indeed, if everybody's expecting a
nice, orderly resize, and the program suddenly starts getting told the data it
is trying to move simply cannot exist, I would want it to halt and scream
bloody murder about the problem.
--
Ben <dragonhawk at iname.com>
More information about the gnhlug-discuss
mailing list