Date: Tue, 18 Dec 2007 14:43:17 +0200 From: Diomidis Spinellis <dds@aueb.gr> To: Alfred Perlstein <alfred@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG, Bruce Evans <brde@optusnet.com.au>, src-committers@FreeBSD.ORG, Diomidis Spinellis <dds@FreeBSD.ORG>, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/tools/regression/bin/mv regress.sh Message-ID: <4767C065.2040304@aueb.gr> In-Reply-To: <20071218100355.GR16982@elvis.mu.org> References: <200712180849.lBI8nmEi088947@repoman.freebsd.org> <20071218100355.GR16982@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > Does 'mv' spawn off tar or something to do the copy part? > > You can _usually_ get much better cross device performance > by hooking two processes together like so: > > tar -cf - -C /path/to/source . | tar -xf - -C /path/to/dst > > This will keep the disks a lot busier, but this can make > things worse on cross device moves that happen to be > on the same disk. > This is an interesting idea. Currently, mv spawns off cp and rm when rename fails with EXDEV. Given that our cp often uses mmap to avoid the read/write context switching, I'm not sure that using a tar pipe will buy us a lot of performance. Anyway, the major problem is now the semantics of POSIX for cross-device links. The regression tests I wrote succeed in all rename(2)-based tests. Running *the same tests* across devices on FreeBSD, Solaris, and Linux gives us three different sets of failed tests. Also, a literal reading of POSIX seems to require mv to loose some data or leave data lying around when some parts of the cp/rm dance fail. As bde@ pointed out in a private email, my initial implementation was intepreting POSIX too liberaly in this respect, trying to avoid data loss, so this also probably needs changing. I'm discussing these aspects with bde@ off-list. If anybody else wants to to be cc'd, drop me a line. Diomidis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4767C065.2040304>