Subject: Aliases: Are alternate filesystems worth trying?

From: "Richard Goldman" <[email-masked]>
Date: Fri, 18 May 2001 13:32:19 -0400

Dear People,

A question, please, and your knowledge, and even guesses would 
be much appreciated:

I know from previous discussion that Macintosh aliases become 
"unhinged" from the files or directories they are supposed to point 
to because the alias contains some kind of ID (did?  inode?) that 
gets recycled by Linux.  Because of this (and the fact that the 
absolute path of the file isn't stored in the alias), the Mac alias can 
end up pointing somewhere else entirely.  At least such is my 
understanding.

So here's the question:

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?

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 
???

Thank you in advance for your time and thoughts.

Sincerely,
Richard

---

From: Stephen VanPelt <[email-masked]>
Date: Fri, 18 May 2001 14:14:19 -0400

Richard,

I've got a Redhat 7.1 box up running SGI's newly released (at least, newly 
released outside of their own systems) XFS file system.  In my trials, I'll 
check it out to see if this is a problem on my platform, and I'll let you 
know.

Stephen VanPelt
Information Technology Consultant
MUSC Center for Drug and Alcohol Programs
PH: 843-792-5558 Internet:   [email-masked]

__________________BEGIN FOOTER___________________
**The Views Expressed by the Author of this Message are not **
**necessarily those of the Medical University of South Carolina**

--On Friday, May 18, 2001 1:32 PM -0400 Richard Goldman 
<[email-masked]> wrote:

> 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?
>

Stephen VanPelt
Information Technology Consultant
MUSC Center for Drug and Alcohol Programs
PH: 843-792-5558 Internet:   [email-masked]

__________________BEGIN FOOTER___________________
**The Views Expressed by the Author of this Message are not **
**necessarily those of the Medical University of South Carolina**

---

From: Thomas Schierle <[email-masked]>
Date: Fri, 18 May 2001 21:59:25 +0200

On 01-05-18 19:32 +0200, "Richard Goldman"<[email-masked]> wrote:

> [ ... ]
> gets recycled by Linux.
> [ ... ]

DIDs (directory IDs) to the best of my knowledge are unique to
HFS/HFS+ volumes. Every file on a HFS volume gets a *true* unique
identifier ID assigned -- the ID number will never ever get recycled
for a given volume.

> these ID's, or is it due to the nature and operations of the ext2

netatalk assigns non-permanent DIDs just in RAM for a users session,
if that user logs out, DIDs get flushed from memory

> 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!

-- 
Thomas Schierle, Munich, Germany

PGP key [DSS/DH] 0xA23CDA1D available at various public key servers

---

From: Matthew Geier <[email-masked]>
Date: Sat, 19 May 2001 16:10:59 +1000

> 1.5pre6 compiled with permanent DIDs works as advertised for me :-)

 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...

---

From: Matthew Keller <[email-masked]>
Date: 19 May 2001 13:10:36 -0400

From a programatic design standpoint, Netatalk needs to be
    filesystem dumb for maximum portability. These problem need to be
    overcome internally. Sure, we could have a --with-xfs switch (just
    as an example) which can optimize itself for any given filesystem,
    but there still needs to be internal resolution of this issue.

-- 

Matthew Keller
Enterprise System Analyst
Computing & Technology Services
Information Services Division
State University of NY at Potsdam
Potsdam, NY USA

http://mattwork.potsdam.edu/