Re: A request/suggestion for the behavior of chmod -X

On Sat, Mar 7, 2009 at 2:55 AM, Charles Jie wrote: > Hi, > > Situation: > >    I often need to pull lots of files from Windows boxes or from SD >    cards in FAT filesystem filled with photos from digital camera. > >    The copied files usually have the x-bit enabled, which I hate very >    much i

Re: sort -g (generic numeric) is working only for the first key

Hi Anreas / Eric, > Erik Auerswald writes: > > >> Hi Wasim, >> >> On Sun, Mar 01, 2009 at 08:09:43PM +0530, Wasim Akram S.N. wrote: >> >>> Hi, >>> I don't know whether the following is really a bug. >>> ... >>> wa...@wasim:~/temp$ sort -g -k1,3 -t \t a >>> >> This tells sort to rega

A request/suggestion for the behavior of chmod -X

Hi, Situation: I often need to pull lots of files from Windows boxes or from SD cards in FAT filesystem filled with photos from digital camera. The copied files usually have the x-bit enabled, which I hate very much in Unix-like systems. With it, the colored 'ls' output is not

Re: Degraded performance in cat + patch

I was thinking a bit more about the patch just pushed. It sets the buffer size to 8*st_blksize which seems a little arbitrary, and also max buffer size is set to 32KiB even if the file system has a larger st_blksize. I'm not sure this is desired? How about making 32KiB the minimum as in the attach

Re: Degraded performance in cat + patch

Pádraig Brady wrote: ... > Wow that's interesting. My results are with 400MHz DDR2. > If I do a simpler test excluding file-system and page cache > to just show the syscall overhead I can also see the doubling > of throughput when going from 4KiB to 32KiB buffers: > > for i in $(seq 0 10); do > b

Re: Degraded performance in cat + patch

Jim Meyering wrote: > Pádraig Brady wrote: > ... >> Why such a huge syscall overhead? Testing with dd on a >> 1.7GHz pentium-m with 2.6.24.5-85.fc8 shows much less: > > Probably due to my faster memory, caches, etc. > The systems I tested on have 800MHz and 667MHz DDRII. > I suspect that the relat

Re: Degraded performance in cat + patch

Pádraig Brady wrote: ... > Actually reading your preformance results more closely showed > the throughput actually doubled? That surprises me. My 50% was *speed-up*. Of course, throughput is the inverse: 2x. > Why such a huge syscall overhead? Testing with dd on a > 1.7GHz pentium-m with 2.6.24.5

Re: Degraded performance in cat + patch

Pádraig Brady wrote: > Pádraig Brady wrote: >> Jim Meyering wrote: >>> >From 6dd9c564a0cba6eec95102f091c6692a5ab48876 Mon Sep 17 00:00:00 2001 >>> From: Jim Meyering >>> Date: Fri, 6 Mar 2009 10:27:43 +0100 >>> Subject: [PATCH] cat: use larger buffer sizes to reduce read/write-syscall >>> overhea

Re: Degraded performance in cat + patch

Pádraig Brady wrote: > Jim Meyering wrote: >> >From 6dd9c564a0cba6eec95102f091c6692a5ab48876 Mon Sep 17 00:00:00 2001 >> From: Jim Meyering >> Date: Fri, 6 Mar 2009 10:27:43 +0100 >> Subject: [PATCH] cat: use larger buffer sizes to reduce read/write-syscall >> overhead >> >> * src/cat.c (max): Re

Re: Degraded performance in cat + patch

Jim Meyering wrote: > >>From 6dd9c564a0cba6eec95102f091c6692a5ab48876 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Fri, 6 Mar 2009 10:27:43 +0100 > Subject: [PATCH] cat: use larger buffer sizes to reduce read/write-syscall > overhead > > * src/cat.c (max): Remove definition. Use MAX f

[PATCH] maint: avoid new unused-macro warnings from gcc

Building on just-updated rawhide, I saw a bunch of new failures due to warnings (treated as errors via -Werror) from the latest version of gcc. This makes "make" complete without error once again: >From 8b638f994abefde84746b3d8a08893c9ffeb7799 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri

[PATCH] tests: fix just-introduced typo in rm/ext3-perf

I just noticed a typo that could make one of the most "expensive" tests fail. Here's the fix: >From 5d71171e01fb7f585fc3864866c0a30a4064380f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 6 Mar 2009 11:12:32 +0100 Subject: [PATCH] tests: fix just-introduced typo in rm/ext3-perf * tests/

Re: Degraded performance in cat + patch

Tzvi Rotshtein wrote: > I've been using "cat" to feed large files into some data cruncher > application using something like this: >cat my_data | data_cruncher > > However, cat was reading/writing the file in sub-optimal speeds (not even > half as fast as the disk & os can provide it). I traced

Re: Degraded performance in cat + patch

Tzvi Rotshtein wrote: > Hi, > I've been using "cat" to feed large files into some data cruncher > application using something like this: >cat my_data | data_cruncher Well ideally you should just `data_cruncher < my_data` and the operating system should handle getting the data from disk in the