Re: "HISTSIZE=999999999" cause bash failure after lastest upgrade

Hello Chet, I'm replying to a 2-year old bug; I think it's still relevant. subject: "HISTSIZE=9" cause bash failure after lastest upgrade link: https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00113.html text bellow: > > Bash Version: 4.4 > > > Patch Level: 0 > > Release Status: re

Re: "HISTSIZE=999999999" cause bash failure after lastest upgrade

On 8/16/17 9:34 AM, Klaas van Schelven wrote: > > I'm on GNU bash, version 4.4.5(1) myself. And you tested with this version? > > I'm not sure the solution mentioned above is sufficient to solve all > relevant variant problems caused by the pre-allocation of the memory. It appears to work with

Performance issue of find function in Gluster File System

Hi, I found there is a big difference of time performance between "ls" function and "find" function in Gluster File System . Here is the minimal working example. mkdir tmp touch tmp/{000..300}.txt time find

Re: Performance issue of find function in Gluster File System

Zhao Li wrote: So I am wondering what C code you use for "ls" and "find" and how you explain "*" in "ls" and "find" to lead to this big difference in Gluster File System. --- Nothing to do with Gluster, bash, ls or find, but w/the example. I did both w/output to files in ./tmp -- you need

Re: Performance issue of find function in Gluster File System

On Wed, Aug 16, 2017 at 11:02 PM, Zhao Li wrote: > Hi, > > I found there is a big difference of time performance between "ls" function > and "find" function in Gluster File System > ide/GlusterFS%20Introduction/>. > Here is the minima