From owner-freebsd-current Mon Dec 16 17:41:03 1996
Return-Path: <owner-current>
Received: (from root@localhost)
by freefall.freebsd.org (8.8.4/8.8.4) id RAA23270
for current-outgoing; Mon, 16 Dec 1996 17:41:03 -0800 (PST)
Received: from gaia.coppe.ufrj.br (root@cisigw.coppe.ufrj.br [146.164.2.31])
by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA23265
for <current@FreeBSD.ORG>; Mon, 16 Dec 1996 17:41:00 -0800 (PST)
Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.3/8.7.3) id XAA02665; Mon, 16 Dec 1996 23:40:30 -0200 (EDT)
From: Joao Carlos Mendes Luis <jonny@mailhost.coppe.ufrj.br>
Message-Id: <199612170140.XAA02665@gaia.coppe.ufrj.br>
Subject: Re: Warning -- Lite/2 merge coming up
To: mark@grondar.za (Mark Murray)
Date: Mon, 16 Dec 1996 23:40:30 -0200 (EDT)
Cc: toor@dyson.iquest.net, current@FreeBSD.ORG
In-Reply-To: <199612161414.QAA20372@grackle.grondar.za> from Mark Murray at "Dec 16, 96 04:14:25 pm"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
"John S. Dyson" wrote:
> > What about the other broken FS's, like union and null?
> >
> We have been holding off until the Lite/2 merge. Lite/2 might fix
> some of the problems.
Sometime ago I was reading the unionfs algorithm on the 4.4 BSD book.
One problem that came to my mind was about the deleted files.
It says that if one file on the lower layer is deleted, as it shall not
be really deleted, an entry on the upper layer directory is created with
the I-node 1.
Ok, when I dismount the union, how will this I-node 1 behave ? Is it
valid ? Should it be ignored or deleted ? What's its type ?
When I remount the union, shall the lower "deleted" file exist or not ?
If I compare unionfs to linkdir, "dismounting" should give a ENOENT
error to the syscall attempting to access the I-node 1 file. Also,
both keeping or not the "deleted" file approaches can be obtained.
And, the final problem: When making a copy from lower to upper layer
(to permit a write access to some file) should this be done by the
kernel ? Is it a good approach ? This could mean a very large
operation, and I don't like to keep the kernel busy for such a long
time. Maybe a daemon implementation (just like portal) should do
this job better.
Jonny
BTW: Is this discussion better suited on -hackers ?
--
Joao Carlos Mendes Luis jonny@gta.ufrj.br
+55 21 290-4698 ( Job ) jonny@cisi.coppe.ufrj.br
Network Manager UFRJ/COPPE/CISI
Universidade Federal do Rio de Janeiro