On 5 Oct, Pat Dirks wrote:
Sorry if I'm talking nonsense or if somebody else already pointed this
out, i usually just lurk around this list, but if I'm right I think it
is of sufficient significance...
> ADOPTING "FOREIGN" FILESYSTEMS
>
> When a new, never before seen disk is first mounted in the system it's
> treated as "foreign". This can be changed (with "root" permissions) to
> make the filesystem "local". The filesystem's ID is added to the list of
> local filesystems and forever after when the disk is mounted it's treated
> as "local". As part of this "adoption" process the users is prompted to
> choose one of two ways to handle the existing permissions on the disk:
Adding the filesystem to the systems list of local filesystems is not
going to guarantee that the filesystem is local at all. If you move a
disk from machine A to machine B, both machines will know the disk with
that ID to be local. Moving the disk back to machine A will cause it to
accept a filesystem as "local" that is actually "foreign".
The "solution" would be to remove it's ID from the list when the
filesystem is removed from the system, but AFAIK the only way to detect
that is the "umount" that is required to do such. However, an umount
is not enough reason to unmark a filesystem as "local"; it also
happens at reboot, to name just one of the many occurances of umount.
As may become obvious, I'm not an expert at this at all.
I would rather brand the filesystem with the ID of the host. The
starting situation is an "unmarked" filesystem. If a host detects the
mounting of an "unmarked" filesystem, it will brand it with it's ID. If
it detects a filesystem that has an ID that differs from the host's ID,
it is a foreign filesystem. Seems quite simple to me...
--
Alban Hertroys.
http://wit401310.student.utwente.nl
---
If I had a sig it would be fun.
The quest for the Holy Sig has begun.
I have not yet a clue,
What will you see next issue?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message