Subject: Re: Disappearing files.....[long, new case/infos]

From: BWS - Offwhite <[email-masked]>
Date: Wed, 6 Dec 2000 14:50:02 -0600 (CST)

Does this mean the problem is limited to the ext2 filesystem or is this
simply a universal inode problem?  It sounds like one FreeBSD user had the
problem so I would guess it is a universal problem.

Is there a way to control the inodes to keep them from being a problem
with Netatalk?  I typically keep my drives under 20 gigs per partition so
that could be why I am not having problems, but I have a new IDE drive
which is 30gigs and I would not like to lose any data there.
Brennan Stehling - web developer and sys admin
projects: www.greasydaemon.com | www.onmilwaukee.com | www.sncalumni.com

This signature is just here to take up space.

---

From: "Robert B. Bell" <[email-masked]>
Date: Wed, 06 Dec 2000 12:58:45 -0800

> problem so I would guess it is a universal problem.

It is a universal problem,
I just know the ext2 details since that is what I use.
I don't know what filesystem is used with FreeBSD,
so I don't know if it is more or less common of a problem.

> with Netatalk? 

The only way you can control the number of inodes
is when you create the filesystem.

with the ext2 filesystem (see "man mke2fs"),
you add the option "-N <number of inodes>" to the mkfs command.

with Solaris 2.5.1, the "newfs" command has "-i <bytes per inode>"
option to limit the number of inodes.
You would have to to a "df -i" to see when you actually got.

  Robert.

---

From: "lists-mail" <[email-masked]>
Date: Wed, 6 Dec 2000 23:49:32 -0000

For what it's worth, none of my drives exceed 18gb. Two drives on each machine 
are partitioned as a single slice, /usr/local/www and /usr/local/media. Both 
are 18gb 10k SCSI UW drives and hold the server root for the development 
server. The drive experiencing the problem is /usr/local/www.

DAve

--

---

From: "Jonathan Newman" <[email-masked]>
Date: Wed, 6 Dec 2000 16:45:00 -0800

> From: BWS - Offwhite [mailto:[email-masked]]

> which is 30gigs and I would not like to lose any data there.

If I am reading the code correctly, the encoding works as follows:

four bits are used for the major device number
three bits are used for the minor device number
one bit is used to indicate a file or not
The remaining 24 bits are used for the inode (with the top byte of the
4 byte inode being shifted down 8 and xor'd with the lower 24 bits)

So if your major device number is greater than 15, or your minor
device number is greater than 7, or your inode values exceed
16,777,215 then you may run into problems.  For us, it is the minor
device number that is the issue.  I suppose things could be re-encoded
to be more amiable to larger numbers of devices, but it is just an
arbitrary solution, IMO.

Jon

---

From: "Robert B. Bell" <[email-masked]>
Date: Wed, 06 Dec 2000 17:40:01 -0800

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.

Do a "df -i" and check your inode created number (the left most number).

  Robert.

---

From: Matthew Wilson <[email-masked]>
Date: Thu, 7 Dec 2000 09:39:20 -0800 (PST)

> to be more amiable to larger numbers of devices, but it is just an

I've got 4 100+ GB RAID volumes to deal with.  They are on a mulit-host
external controller, so they just look like /dev/hda1 -> /dev/hdd1.  24
bits is fine for inodes, as there are only 13,000,000 or so.  The problem
is the same as yours, the minor device number.  mine are 1,17,33 and
49.  So here's a question, in my case, as all the major numbers are the
same (8), would itbe evil to hack this hash function to give the major
bits to the minor?
 
also, the the bit to determine if it's a file or not neccesary?

another question, what if netatalk stopped giving out DIDs?  What if every
time the Mac asked for DID xxx, netatalk asked for the full path? Yes, a
performance hit, but I'll take a performance hit over lost data any day.

Matthew

---

From: "Jonathan Newman" <[email-masked]>
Date: Thu, 7 Dec 2000 11:35:34 -0800

> so.  The problem is the same as yours, the minor device number.
> mine are 1,17,33 and 49.  So here's a question,
> in my case, as all the major numbers are the

Evil?  Only malicious software is evil in my book.  The change you
describe would be a short term fix for your issue, but certainly not a
long term one for everyone.

> also, the the bit to determine if it's a file or not neccesary?

I believe it is needed for differentiating file/dir entries in the
red-black tree.

> another question, what if netatalk stopped giving out DIDs?

There is a better (temporary) solution.  Specify --enable-lastdid at
./configure time, and netatalk will generate unique DIDs for a given
run of afpd.  This means that aliases on some versions of the MacOS
won't work correctly to items inside netatalk volumes between mounts
of a volume (say that three times fast...)

The reality is that we need a persistent DID database for netatalk.
Unfortunately, it seems no one has the time to commit to such a
project.

Jon

---

From: Netatalk <[email-masked]>
Date: Fri, 8 Dec 2000 10:51:43 +0100

> 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
[email-masked]

---

From: "Jonathan Newman" <[email-masked]>
Date: Fri, 8 Dec 2000 07:35:15 -0800

>   available unused ID is to be chosen.

... snip ...

> was working in this direction, but I don't know how far it got).

The lastdid solution address (a) and for a given run of afpd also
holds true for (b).  If the lastdid solution was persistent, it would
satisfy (b) completely.

The "lastdid" solution merely keeps track of how many entries in the
database were created and numbers them sequentially.  Unfortunately,
if I am reading the code correctly, the current database is generated
per instance of afpd -- one per login.  My concern is the
syncronization of this database between multiple afpd instances.  It
adds a new dimension of complexity to the problem.

Jon

---

From: David R Bosso <[email-masked]>
Date: Fri, 08 Dec 2000 08:19:56 -0800

> was working in this direction, but I don't know how far it got).

I think a database mapping an (arbitrary, persistent) ID with a 
device/inode would have the advantage of maintaining the ID if the entity 
was moved on the same volume.  Do you see any disadvantages to using 
device/inode over fileystem-name as the database key?

-David

---

From: Jürgen Weltzer <[email-masked]>
Date: Fri, 8 Dec 2000 17:29:04 +0100

I'm working with 1.4b2+asun2.1.4pre39-5.

Does the problem only occur with the new version - or must I be angry 
about disappearing files?

I'm serving a 8GB Volume to 6 Macs. I have only DID Conflicts when a 
user changes a file- or directory name from the Macs Finder - but no 
disappearing files. But I have to upgrade to a 30GB Volume...

In case of conflict the message log tells:
"DID conflict: file A and file B are these the same files?"

Sometimes when this occurs, a Mac can see the file - but can't open 
it (file not found). After a reboot of the Mac all works fine.
-- 
Viele Grüße
Jürgen Weltzer

- - - - - - - - - - - - - - - - - - -
Werbeagentur Weltzer
Max-Eyth-Straße 8
71065 Sindelfingen
Tel. +49 (0) 70.31.81.32.31
Fax +49 (0) 70.31.81.16.01
http://www.w-ww.de/
- - - - - - - - - - - - - - - - - - -

Windows95/98/NT: 32 bit extension and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company, that can't stand 1 bit of
competition

---

From: andrew morgan <[email-masked]>
Date: Fri, 8 Dec 2000 09:37:57 -0800 (PST)

> adds a new dimension of complexity to the problem.

Really the DID should be a database stored on the filesystem somewhere, so
that not only are DIDs the same across all afpd instances, but between
reboots as well.  New versions of samba will use 'tdb' (tiny-db) as their
database for storing user information, etc.  This is something the samba
team has written.  The advantages are that it is very lightweight because
it only has basic database features.

	Andy