Newsgroups: comp.archives
Path: utzoo!news-server.csri.toronto.edu!ox.com!emv
From: stefano@angmar.sublink.ORG (Stefano Longano)
Subject: [comp.unix.internals] Re: Why is restore so slow?
Message-ID: <1991Mar9.064522.27785@ox.com>
Followup-To: comp.unix.internals
Sender: emv@ox.com (Edward Vielmetti)
Reply-To: stefano@angmar.sublink.ORG (Stefano Longano)
Organization: Home Sweet Home, Rovereto (TN) Italy
References: <50235@olivea.atc.olivetti.com> <1013@eplunix.UUCP> <BZS.91Mar3135546@world.std.com> <480@appserv.Eng.Sun.COM> <1637@angmar.sublink.ORG>
Date: Sat, 9 Mar 1991 06:45:22 GMT
Approved: emv@ox.com (Edward Vielmetti)
X-Original-Newsgroups: comp.unix.internals

Archive-name: library/usenix/sprite-lfs/1991-03-06
Archive: sprite.berkeley.edu:/lfsUsenix90.ps [128.32.150.27]
Original-posting-by: stefano@angmar.sublink.ORG (Stefano Longano)
Original-subject: Re: Why is restore so slow?
Reposted-by: emv@ox.com (Edward Vielmetti)

In <480@appserv.Eng.Sun.COM> lm@slovax.Berkeley.EDU (Larry McVoy) writes:


>I believe that a key component to the slowness of restore is the synchronous
>nature of directory operations in the Unix file system.  For example, a create,
>something that occurs quite often in restore :-), is synchronous.  It has to
>be, those are the semantics of a Unix file system (can you say lock files?).

These operation need not to be syncronous to retain the semantics of the
Unix file system. You could read the paper presented at the Summer '90 USENIX
Technical Conference by Mendel Rosenblum and John Ousterhout about the
Sprite Log-structured File System. This paper is available for anonymous FTP
from sprite.berkeley.edu.
-- 
Stefano Longano           WW           WW    EMAIL : stefano@angmar.sublink.ORG
Viale Trento 1            ||wwwwwwwwwww||     Happy are those who dream dreams
38068 Rovereto (TN)       ||    ---    ||      and are ready to pay the price
Tel : +39 (464) 436042    ||____|_|____||          to make them come true
