[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] GNU TAR or STAR -- speed comparision

From: Joerg Schilling
Subject: Re: [Bug-tar] GNU TAR or STAR -- speed comparision
Date: Thu, 18 Oct 2007 22:03:33 +0200
User-agent: nail 11.22 3/20/05

Jan-Benedict Glaw <address@hidden> wrote:

> > > > So test again with "star -no-fsync ..."
> > >
> > > Is `-no-fsync' the only difference?  How much more secure does this
> > > make star over tar?  My guestimation tells me that there's only really
> > > a difference in case of a system crash during/right after tarball
> > > extraction.
> > 
> > I have seen unfixable (via fsck) filesystemn corruption on Linux after a
> > power outage a short time after extracting a bigger filesystem tree.
> Yeah, old story.  We've seen SIGSEGV'ing fscks, too. (Though I've
> never seen that with Linux + ext[23].)

I've seen this about 5 times with Linux and ext2. I am not sure about ext3.

> However, I think it's not tar's task to ensure that all data is
> written to a stable medium. Tar has to ensure that, after exit()ing,
> all files are ready to be accessed and match the expectation.

You cannot do the latter if you do not do the first.

> > If you like to evaluate the exit code of any tar, this only makes
> > sense if the tar implementation calls fsync() before close(). If it
> > does not call fsync(), a zero exit code does not grant anything.
> It does grant me that if I start any filesystem operation (or mmap()
> or whatever), this'll succeed. But I don't think it's tar's business
> to mimic a database server or anything else that must be
> "transactionally" safe.  If you want that, maybe a data-journaling
> or sync-mounted filesystem is what you actually want to deploy.

Before vi started to call fsync() around 1987, many people did loss files
that have been NFS mounted as a result of a late filesystem fill up.

> > Star (called under the name "star") implements other deviations from the
> > behavior of the classical UNIX tar, e.g. different defaults for the unlink()
> > setup in extract mode.
> Hopefully it doesn't try to unlink() directories :->

I did write that star tried to be more safe in it's behavior...


 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

reply via email to

[Prev in Thread] Current Thread [Next in Thread]