[openbeosstorage] Re: session module
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 21 Feb 2003 20:45:52 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > > Right, that would be another good idea as long as we don't
> > > > allow
> > > > our
> > > > users to resize partitions and move them around :-)
> > > > (which will be perfectly true for R1)
> > > Even then I see no problem, since the system would update the
> > > data.
> > Of course, that would only be possible when the system knows about
> > all
> > the mount points to be updated.
> > If we don't have that global mount settings file, and the file
> > system
> > can't query reparse points, only the settings of mounted volumes
> > could
> > be updated.
> Mmh, I can't follow here. Since the actual partitioning is done in
> kernel, it should know, which partitions are concerned, even, if they
> aren't mounted. Or do I miss something=3D3F
I think so. What I was referring to was this: you have a reparse point
that creates a point in /boot/home/mail. That reparse point is stored
in the attributes of the real BFS directory /boot/home/mail, but it's
not yet mounted, since the system had no reason to do so yet.
Now, you change the partition that this mount point referred to - if
the reparse point has used the partition size/offset to identify the
partition, the situation that I tried to explain above arises: the
system doesn't necessarily know about the reparse point, and thus, it
can't update it.
Clearer now=3F
BTW I think that only the real partition device should be used for
those automatic reparse points - after all, that's the most secure
value since the order and number of partitions rarely changes.
Of course, we could have a global table that maps unique IDs to
partitions, and those can be updated automatically if anything changes.
But this would also be problematic, if you wanted to use a permanent /
floppy/ kind of mount point (or in other words, for removable devices).
That's why I would say: screw that additional data for system
maintained mount points, and only have /dev/disk/.../master/0=5F1 and the
like as references.
Adios...
Axel.
- Follow-Ups:
- [openbeosstorage] Re: session module
- From: Ingo Weinhold
- References:
- [openbeosstorage] Re: session module
- From: Ingo Weinhold
Other related posts:
- » [openbeosstorage] session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- » [openbeosstorage] Re: session module
- [openbeosstorage] Re: session module
- From: Ingo Weinhold
- [openbeosstorage] Re: session module
- From: Ingo Weinhold