[ale] why would it take longer to delete a file than to createit?

[Doug McNash]

Just a guess.
Filesystems like reiser and xfs could be slower on delete than say FAT because they keep inodes and other information in btrees that may need rebalancing on deletions.  FAT and probably others have fixed tables that just need the block table entries marked as free. Plus the former are usually bigger.
--
doug mcnash

---- Greg Freemyer <greg.freemyer at gmail.com> wrote: 
> Is that on an idle disk/array?
> 
> That would be very slow.
> 
> But if its busy serving db queries, its not surprising.
> 
> On Wed, May 5, 2010 at 4:45 PM, John G. Heim <jheim at math.wisc.edu> wrote:
> > Doh! Caching... I shoulda thunk of that myself.
> >
> > But now the question is why does it take so long to write a 1 Gb file?  I
> > ran this same test on a half dozn computers and none of them took this long.
> > When I ran the command below, with the "conv=fsync" parameter, it took 3
> > minutes on my DB server.
> >
> >
> >
> > ----- Original Message -----
> > From: "Greg Freemyer" <greg.freemyer at gmail.com>
> > To: "Atlanta Linux Enthusiasts - Yes! We run Linux!" <ale at ale.org>
> > Sent: Tuesday, May 04, 2010 7:22 PM
> > Subject: Re: [ale] why would it take longer to delete a file than to
> > createit?
> >
> >
> > Try it as:
> >
> > date; dd if=/dev/zero  of=zero.txt bs=1024 count=1000000 conv=fsync;
> > date; rm zero.txt; date
> >
> > note the extra conv=fsync arg
> >
> > Greg
> >
> > On Tue, May 4, 2010 at 6:29 PM, John G. Heim <jheim at math.wisc.edu> wrote:
> >> I have this very slow database server. Today I noticed something strange
> >> about it. I can create a large file via dd faster than I can delete it.
> >> Look at the screen cap below... It took just 12 seconds to create the file
> >> with a million 1K records but it took 36 seconds to delete it. Why would
> >> that be? I'm running debian lenny with a 2.6.30 kernel. There are 2 500 Gb
> >> disks in the machine configured as RAID-1. The file system on the disk is
> >> ext3.
> >>
> >> # date; dd if=/dev/zero of=zero.txt bs=1024 count=1000000; date; rm
> >> zero.txt; date
> >> Tue May 4 16:59:21 CDT 2010
> >> 1000000+0 records in
> >> 1000000+0 records out
> >> 1024000000 bytes (1.0 GB) copied, 11.7291 s, 87.3 MB/s
> >> Tue May 4 16:59:33 CDT 2010
> >> Tue May 4 17:00:09 CDT 2010
> >>
> >> _______________________________________________
> >> Ale mailing list
> >> Ale at ale.org
> >> http://mail.ale.org/mailman/listinfo/ale
> >> See JOBS, ANNOUNCE and SCHOOLS lists at
> >> http://mail.ale.org/mailman/listinfo
> >>
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
> 
> 
> 
> -- 
> Greg Freemyer
> Head of EDD Tape Extraction and Processing team
> Litigation Triage Solutions Specialist
> http://www.linkedin.com/in/gregfreemyer
> CNN/TruTV Aired Forensic Imaging Demo -
>    http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/
> 
> The Norcross Group
> The Intersection of Evidence & Technology
> http://www.norcrossgroup.com
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo