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