
|
[openbeosstorage]
||
[Date Prev]
[04-2003 Date Index]
[Date Next]
||
[Thread Prev]
[04-2003 Thread Index]
[Thread Next]
[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2003 17:43:15 +0200 CEST
"shatty" <shatty@xxxxxxxxxxxxx> wrote:
> Somebody wrote:
> > But anyway, it *is* a problem, and we will not be=3D20
> > able to solve it completely (and efficiently when=3D20
> > complete), due to the heavy usage of entry=3D3D3D5Frefs=3D20
> > in BeOS.
> An offset in the in-memory data structure representing
> a volume/partition/whatever can efficiently and simply
> solve this problem assuming that you are simply going=3D20
> to move everything linearly.
>
> You don't even have to remember which entry=5Frefs were
> from before the move. You can treat them all the same
> by subtracting the offset every time you create an
> entry=5Fref.
> ...
How is that supposed to work=3F
The entry=5Frefs thing only happens when resizing or defragmenting a file
system. Because there, the on disk location of files can be changed,
and thus an entry=5Fref might be rendered invalid through that action.
When a partition is moved around, the file system doesn't even have to
be aware if it doesn't use absolute block addressing - and that's only
used by iso9660 and UDF - both are very unlikely to be found on a hard
drive.
Adios...
Axel.
|

|