Subject: Changing Aliases ... and how to fix?
From: Roland Schulz (fi111@fen.baynet.de)
Date: Thu Jun 26 1997 - 21:22:49 EDT
Hi ...
I have been away for some days so I could not respond earier... but since
the recent discussions in linux-atalk showed that there is a wide interest
in this topic I'd like to comment on some ideas mentioned here ...
I will talk about DIDs (directory ids) a lot, since these are the ones where
the problems start, the file-ids are not so much of a problem since they're
not used to lookup a file when an alias is resolved. I made a few changes to
1.3.3 and later to 1.4b2 to support aliases with certain restrictions,
notably one mountpoint/volume, which I can mail to interested folks that
can live with this restriction.
> >A better solution would be to place a single file at the root of the
> >mounted volume containing, basically, the contents of afpd's directory
>
> To have that information in a single file is not very handy in the =
> long run. If you e.g. move or remove a file using 'mv' or 'rm', you =
> would leave this database file out of date! The inode number strategy =
> looks very elegant to me. Why isn't that handled this way in the =
> current netatalk?
To have it distributed over the filesystem would be equally bad, imagine this:
a directory is created and assigned it's DID. Now someones copies (on the unix
side) the directory someplace else. This way the new and the old dir would have
an equal DID. Now what? Keep in mind that we don't have a creation date
on unix to see which dir is older.
As with the database getting out of sync: one must always consider
inconsistencies in a caching situation, and a single database would be a cache
of some sort. The above situation could be easily solved with the single
database since it has one entry for the DID, and the other will not have one,
so it can be assigned a new DID.
Even if you use inodes as DIDs, you cannot avoid the central database file
since:
> But the inode aproach does have problems. Althoug UNIX internally does
> all file accesses using inodes, the system call interface does not
> provide any means to use inodes to access files. So accessing a file
> by inode is expensive (if done in user space). NFS server typically
> run inside the kernel, and so they can access the files using the
> inode number. So this aproach probably would have to be implemented in
> kernel, to be efficient.
Not necessarily.
This is where central database file in the volumes root comes into play.
This file is a simple array indexed by inode that provides for each Mac-created
or Mac-visited directory the inode number of its parent. The file is mmapped
by each afpd and updates are made directly when a dir is created/removed/moved.
If a directory is created from the unix side, the inconsistency does not matter
at all, since no mac can have an alias pointing to this directory. If it is
created by a Mac, the file is updated, so aliases work.
One problem with this approach is that it cannot detect when a dir is
deleted and then recreated, getting the same inode as the old dir, which is a
very common case.
> A caveat of the inode number approach would be the handling of =
> deleted files and reused inodes. Suppose file f starts at inode i(f) =
> and alias a points to f. Then, we delete f and create a new file g. =
> If this file's first inode i(g) =3D=3D the former i(f), the alias a =
> automatically would point to it. Isn't that so? Please correct me.
This is the case. You must choose yourself if you can live with it.
> Another problem is the fact, that the inode numbers are only uniqe on
> the UNIX volumes. But netatalk does not export a UNIX volume, but a
> UNIX directory tree, which can contain multiple volumes all having
> their own uniqe inode numbers.
This problem is only one of the many resulting from using the inode as
directory-ID. A recent post in linux-atalk was about using a hash on the
complete filename instead to create the DID. One would need a database
with DID->filename mappings, though. But this database would be host-wide and
could be updated centrally, or shared between afpds via mmap, but careful
synchronisation would be necessary to prevent substantial performance
degradation. This looks very promising and has the potential to solve many
problems of the inode-oriented approach. It has certain drawbacks, too,
since it places more weight on the database file. With the inode-approach,
the database can be regenerated without problems at all since no data is
lost. With the hashed name, hash collisions cannot be rebuilt correctly
every time, so one would need to store the hash value somewhere where it can
be recreated. Or one could argue that the few cases of collisions in a
2^^31 range are rare enough to risk their aliases getting lost.
> >You'd have a simple database that several afpd's could modify at once.
> >The first few routines in etc/afpd/directory.c would need to be
> >modified. The format could be very similar to a Unix directory, with
> >free extents, etc. If a Unix file got deleted with "rm", then the
> >database would be modified by the first afpd to notice the
> >discrepency.
> Sounds much better that the aproach with the singel file in the root
> directory. To check for file removal (and creation or renaming) you
> could store (and check) the directories mtime in the database. Reading
> the directory is only necessary, when it has changed.
But the file in the volume root is outstanding performace-wise. Since it is
just an array of ints, it can be accessed by single uninterruptible reads
and writes or even by normal access on non-smp systems when the file is
mmapped. No lock need be kept and no process need to sleep while waiting for
another since all transactions are atomic. Compare this with a solution which
would need semaphores, even IPC to resolve an alias (not so big a deal) and
when an inconsistency is detected (on EVERY write to the server!)
These arguments reveal again that the idea of keeping a DID for more than
the duration of one session is a fundamental flaw in Appletalk. If one could
force the Mac to resolve an alias not with it's DID/filename pair first but
with it's real filepath (which IS stored in the alias, but only used when the
DID lookup fails, accompanied by an annoying requester which just states that
the alias has changed) these problems could be solved in one swift strike.
Does someone here have a suggestion how this could be affected?
Roland Schulz
fi111@fen.baynet.de
"Life, loathe it or ignore it, you can't like it."
-- Marvin, "Hitchhiker's Guide to the Galaxy"
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:25:13 EST