Re: Aliases: Are alternate filesystems worth trying?


Subject: Re: Aliases: Are alternate filesystems worth trying?
From: Matthew Geier (matthew@arts.usyd.edu.au)
Date: Sat May 19 2001 - 02:10:59 EDT


Thomas Schierle wrote:
>
> On 01-05-18 19:32 +0200, "Richard Goldman"<rgml@graphpoint.com> wrote:
>
> > [ ... ]
> > to because the alias contains some kind of ID (did? inode?) that
> > gets recycled by Linux.

> > Is it Linux itself, at some "virtual" filesystem level, that is re-cycling
> > these ID's, or is it due to the nature and operations of the ext2
> > filesystem?
>
> netatalk assigns non-permanent DIDs just in RAM for a users session,
> if that user logs out, DIDs get flushed from memory
>
> > Put another way, is the alias problem (re: 1.5pre6 and previous)
> > endemic to Linux, or do you think I'll have better luck if I try another
> > filesystem (managable under Linux) such as ReiserFS or ext3 or
>
> 1.5pre6 compiled with permanent DIDs works as advertised for me :-)
> just give it a try!

 The 1.5pre has a 'hack' where DIDs are caculated based on the Inode and
device numbers. This does give persistance. However Inodes get recycled,
no do not make an idea replacement for a DID.
 Linux in particular has an agressive cache. Delete a directory and
immediatly create another and it will recycle the old Inode right away.
NetAtalk can notice this and spit out a DID conflict error into the
system log.
 Depending on your application this may or may not be a problem.
 Different file systems and different unix's have different inode
allocation stragies, all have the same inode recycling possiblity.

 SGI's XFS may be better in this regard as apparently its 'inode'
numbers actually encode a disk address of where to find the file, so XFS
inodes are probably less likely to recycle, but the system could start
(and probably would) allocating blocks for a new file right where one
was just freed and thus end up with the same 'encoded inode'.

 At some point I must try helios lantest on my XFS test volume. It
creates and deletes lots of directories as part of its tests. It can
cause a 'DID conflict' message every time. The conflict message however
doesn't impact on lantest at all.

 In my application, most NetAtalk users are using their own space, I
don't have a situtation where large numbers of directorys are being
created and distroyed all the time in a common share accessed by many,
where a re-used DID could cause havok...




This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:40 EDT