This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Snapshot speed on managing files
On Sat, 13 Jan 2007, Corinna Vinschen wrote:
> On Jan 12 10:34, Brian Ford wrote:
> > On Fri, 12 Jan 2007, Corinna Vinschen wrote:
> >
> > > Current CVS contains a change which is probably the cause for that.
> > > Before deleting a file, the file is moved to the recycle bin.
> >
> > Couldn't we make this conditional only if a "regular" delete fails because
> > the file is in use? Would it then only penalize deletes of open files?
> >
> > (Incidentally, I've noticed this as well.)
>
> I have to pick up the thread at this point again because...
>
> ... because I was just implementing what Dave was asking for. What I'm
> trying to do now is to open the file with the sharing flags set to all-zero.
> If I get a sharing violation I know the file is in use and should be
> moved to the bin. If opening the file worked I can just close the
> handle again and the file will be deleted immediately (delete-on-close
> semantics).
>
> Ok, obviously I needed a testcase to see the speed improvement of this
> method. So I came up with this one:
>
> $ cat > deltest.sh << EOF
> #!/bin/sh
> echo -n "Creating files... "
> for d in `seq -w 1 32`
> do
> mkdir dir$d
> for f in `seq -w 1 32`
> do
> dd if=/dev/zero of="dir$d/file$f" bs=64K count=16 >/dev/null 2>&1
> done
> done
> echo "Ok."
> echo -n "Deleting files ..."
> time rm -rf dir*
> EOF
> $ chmod +x ./deltest.sh
>
> Ok, next thing is taking the time with the current implementation
> which always moves the file to the bin:
>
> $ ./deltest.sh
> Creating files... Ok.
> Deleting files ...
> real 0m2.546s
> user 0m0.233s
> sys 0m0.578s
>
> Huh? 2.5s for what Marco tells us needs 1m40 on his machine?
>
> Anyway, let's try with the new implementation:
>
> $ ./deltest.sh
> Creating files... Ok.
> Deleting files ...
> real 0m2.359s
> user 0m0.187s
> sys 0m0.531s
>
> Can anybody explain to me why moving to the bin should take that
> long on another machine? Apparently the performance hit is barely
> visible on my machine. It's hardly worth to change the code.
>
> Maybe I'm just "suffering" from caching effects? I added a really long
> `find' run between creating and deleting the files, but that made the
> results in both variations even better! 1.4s vs. 1.2s.
>
> So, what's up on the slow machines? Virus checker? But why should an
> open/close sequence not be hit by a virus checker, while an open/move/
> close sequence gets hit that badly? I don't quite get it.
Does <http://cygwin.com/ml/cygwin/2007-01/msg00383.html> seem like a
plausible answer? I'm just reiterating it because it may have been lost
among other suggestions in this thread.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Freedom is just another word for "nothing left to lose"... -- Janis Joplin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/