Subject: Re: Disappearing files..... clarification
From: Netatalk (atalk@abarrach.franken.de)
Date: Fri Dec 08 2000 - 04:51:43 EST
On Wed, Dec 06, 2000 at 05:40:01PM -0800, Robert B. Bell wrote:
> The problems with disk drives on ext2 filesystems was when
> I had 4 GB drives (if I remember correctly).
> The default Inode calculation was too big for that drive
> when the bit mask was 65535 for the inode part.
>
> With one of the newer versions of netatalk+asun,
> A Sun increased the bit mask of the inode from 16 to 24 bits,
> and decreased the major and minor masks.
>
Hi folks ...
While the limited range of bits allocated to the representation of the inode
number might be a problem when large disks are concerned, this is orthogonal
to the problem I described earlier. The two issues here are:
1) Hash collisions between different entities resulting in two objects having
the same ID
2) Reuse of an ID when the old ID is created
The Appleshare documentation is quite firm about the properties the IDs
generated when creating new entities should have:
a) A ID is unique. Two entities with the same ID are the same entity and
vice versa.
b) An ID is never reused unless it is a last resort and then the oldest
available unused ID is to be chosen.
Issue 1) violates a), issue 2) violates b). But while 1) can me minimized
by choosing an appropriate hash function, 2) cannot be avoided with
any filesystem I know except hfs. Either ext2 or reiserfs tend to reuse
their 'inodes' (strictly speaking reiserfs has objectids, not inodes)
very fast, in some cases even instantly after deleting the old one.
So _if_ the Mac really needs b) as it now seems clear it does, I think
a scheme based on inode numbers is bound to fail inevitably.
Question to the Mac Gurus out there: might there be a tool to make the
Mac forget every ID it has stored after the corresponding volume is unmounted?
If not, then we should find a scheme where a) and b) both hold (trivial)
and implement a database mapping ID to filesystem name (I think asun
was working in this direction, but I don't know how far it got).
Any volunteers?:)))
CU
Roland Schulz
atalk@abarrach.franken.de
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:45 EST