[221] in arla-drinkers
Re: arla, an AFS implementation
daemon@ATHENA.MIT.EDU (Magnus Ahltorp)
Fri Aug 21 05:37:30 1998
From owner-arla-drinkers@stacken.kth.se Fri Aug 21 09:37:30 1998
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 14638 invoked from network); 21 Aug 1998 09:37:29 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 21 Aug 1998 09:37:29 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id LAA21756
for arla-drinkers-list; Fri, 21 Aug 1998 11:31:39 +0200 (MET DST)
Received: from yakko.stacken.kth.se (map@yakko.stacken.kth.se [130.237.234.52])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id LAA21743;
Fri, 21 Aug 1998 11:31:16 +0200 (MET DST)
Received: (from map@localhost)
by yakko.stacken.kth.se (8.8.8/8.8.7) id LAA14698;
Fri, 21 Aug 1998 11:30:25 +0200 (CEST)
To: Bjoern Groenvall <bg@sics.se>
Cc: Magnus Ahltorp <map@stacken.kth.se>,
Derrick J Brashear <shadow@dementia.org>, arla-drinkers@stacken.kth.se
Subject: Re: arla, an AFS implementation
References: <Pine.LNX.3.95L.980820201215.5564A-100000@jooky.dementia.org>
<lv1emub1588.fsf@yakko.stacken.kth.se> <wu4sv6oifk.fsf@bg.sics.se>
From: Magnus Ahltorp <map@stacken.kth.se>
Date: 21 Aug 1998 11:30:16 +0200
In-Reply-To: Bjoern Groenvall's message of 21 Aug 1998 10:19:59 +0200
Message-ID: <lv1btpe1y3b.fsf@yakko.stacken.kth.se>
Lines: 18
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
> > This is perfectly normal. I do a lot of magic with the inodes' device
> > numbers. I set the device numbers of the inode to the device numbers
> > of the cached inode to be able to do bmap directly.
>
> According to POSIX, a programmer is allowed to assume that if stat
> returns device and/or inode numbers that are different then one may
> assume that they originate from different files. If device and inode
> numbers are changing this will confuse code seriously, the program
> will be fooled to deduce that the file must have been replaced under
> its feet.
I made a design choice here. I can support that the device numbers are
in some respect "correct", but the cost of this is ugly code that is
unmaintainable. If anyone is willing to change the code and/or the
linux kernel without uglifying the code, fine with me.
/Magnus
map@stacken.kth.se
