Rm performance issue

I am removing 300gb of data spread across 130 files within a single directory and the process take just over 2 hours. In my past experiences removing a small number of large files was very quick, almost instantaneous. I am running red hat Linux on ibm p series hardware against a san with sata and f

Re: Rm performance issue

"Ken Naim" <[EMAIL PROTECTED]> wrote: > I am removing 300gb of data spread across 130 files within a single > directory and the process take just over 2 hours. In my past experiences > removing a small number of large files was very quick, almost instantaneous. > I am running red hat Linux on ibm p

Re: Rm performance issue

On Wed, 26 Sep 2007, Ken Naim wrote: I am removing 300gb of data spread across 130 files within a single directory and the process take just over 2 hours. In my past experiences removing a small number of large files was very quick, almost instantaneous. I am running red hat Linux on ibm p serie

RE: Rm performance issue

[ re-adding bug-coreutils] On Wed, 26 Sep 2007, Ken Naim wrote: I created a test case similar to my nightly job which removes 130 or so 5gb files. The apps* files are identical to files I remove nightly and are 4.3 gb in size, the ctx files are 20mb, and the single letter files are 0 byte fil

Re: FW: Rm performance issue

[it's good to reply to the list, so I've Cc'd it] "Ken Naim" <[EMAIL PROTECTED]> wrote: > I created a test case similar to my nightly job which removes 130 or so 5gb > files. The apps* files are identical to files I remove nightly and are 4.3 > gb in size, the ctx files are 20mb, and the single le

Re: Rm performance issue

Philip Rowlands <[EMAIL PROTECTED]> writes: > unlink shouldn't cause much I/O compared to other read/write > operations, so I'm surprised you only noticed issues with rm. Deleting a big file can require quite a bit of block reading, depending on the filesystem and the fragmentation thereof. Andr

Re: Rm performance issue

"Ken Naim" <[EMAIL PROTECTED]> wrote: > Thanks for your quick reply. > > 1.ext3 > 2. Yes we are using an LVM Now that we've established this isn't a problem with rm, you might want to ask around on ext3- or LVM-specific lists. You might even want to consider using a different type of file system.

RE: Rm performance issue

We are using ext3 on top of LVM on IBM SAN. I don't know the SAN hardware specifics, although I have been trying to squeeze this info out of the client for a while. As for bad io experiences, our core production system use raw devices for our databases so we don't have the same issue(s), this is

[bug #21163] join stops on numeric field if last number before double-digit is missing

URL: Summary: join stops on numeric field if last number before double-digit is missing Project: GNU Core Utilities Submitted by: None Submitted on: Wednesday 09/26/2007 at 18:52 UTC

[bug #21163] join stops on numeric field if last number before double-digit is missing

Update of bug #21163 (project coreutils): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks for the r

Re: Rm performance issue

Ken Naim wrote on 26-09-07 19:19: We are using ext3 on top of LVM on IBM SAN. I don't know the SAN hardware specifics, although I have been trying to squeeze this info out of the client for a while. As for bad io experiences, our core production system use raw devices for our databases so we d

Re: Rm performance issue

On 9/26/07, Ken Naim <[EMAIL PROTECTED]> wrote: > As for bad io experiences, our core production system use raw devices for > our databases so we don't have the same issue(s), this is our production > reporting system that gets cloned over nightly. So the process removes all > the existing files an

Re: Fwd: Re: error.c: "Unknown system error" should report errno value

Hi Eric, On Tue, 25 Sep 2007, Eric Blake wrote: Martin, [offlist] I don't know if you saw this when the discussion migrated to gnulib, but I didn't, thank you. rather than patching error.c, I went with the option of fixing Interix's non-POSIX strerror instead (C99 and POSIX require strerr