similar to: extra readdir operation when writing to a non-existent file

Hello list, I am trying to prepare a USB disk with syslinux that is meant to be able to offer a choice among many different distributions. The goal is that I should be able to dump each distribution's CD contents into a separate subdirectory, and have a master menu that hands off to each distribution's subdirectory. A while back, when faced with a similar task on a PXE server, I came

Check if fs_ops->readdir is available before calling it. At least PXELINUX doesn't implement it. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> diff --git a/core/fs/readdir.c b/core/fs/readdir.c index d2b112b..d20fc33 100644 --- a/core/fs/readdir.c +++ b/core/fs/readdir.c @@ -28,8 +28,11 @@ struct dirent *readdir(DIR *dir) struct file *dd_dir = (struct file *)dir;

Adding devs who work on it On 23 Jan 2018 10:40 pm, "Alan Orth" <alan.orth at gmail.com> wrote: > Hello, > > I saw that parallel-readdir was an experimental feature in GlusterFS > version 3.10.0, became stable in version 3.11.0, and is now recommended for > small file workloads in the Red Hat Gluster Storage Server > documentation[2]. I've successfully

Thank you, Raghavendra. I guess this cosmetic fix will be in 3.12.6? I'm also looking forward to seeing stability fixes to parallel-readdir and or readdir-ahead in 3.12.x. :) Cheers, On Mon, Jan 29, 2018 at 9:26 AM Raghavendra Gowdappa <rgowdapp at redhat.com> wrote: > > > ----- Original Message ----- > > From: "Pranith Kumar Karampuri" <pkarampu at

----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkarampu at redhat.com> > To: "Alan Orth" <alan.orth at gmail.com> > Cc: "gluster-users" <gluster-users at gluster.org> > Sent: Saturday, January 27, 2018 7:31:30 AM > Subject: Re: [Gluster-users] parallel-readdir is not recognized in GlusterFS 3.12.4 > > Adding

We've just been hit rather badly by a very nasty bug that can cause rsync to silently discard files or fill them with zeroes. It happens when e.g. opendir() succeeds but readdir() returns an error; rsync does not check for an error from readdir() and so simply ignores the error (along with any remaining files in the directory). No error is reported to the user, who will then happily

Hi, All, If I set cluster.readdir-optimize to on, the performance of "ls" is better, but I find one problem. # ls # ls files.1 files.2 file.3 I run ls twice. At the first time, ls returns nothing. At the second time, ls returns all file names. If turn off cluster.readdir-optimize, I don't see this problem. Is there a way to solve this problem? If ls doesn't return the

Adding Poornima to take a look at it and comment. On Tue, Jan 23, 2018 at 10:39 PM, Alan Orth <alan.orth at gmail.com> wrote: > Hello, > > I saw that parallel-readdir was an experimental feature in GlusterFS > version 3.10.0, became stable in version 3.11.0, and is now recommended for > small file workloads in the Red Hat Gluster Storage Server > documentation[2].

----- Original Message ----- > From: "Alan Orth" <alan.orth at gmail.com> > To: "Raghavendra Gowdappa" <rgowdapp at redhat.com> > Cc: "gluster-users" <gluster-users at gluster.org> > Sent: Tuesday, January 30, 2018 1:37:40 PM > Subject: Re: [Gluster-users] parallel-readdir is not recognized in GlusterFS 3.12.4 > > Thank you,

Hi Nithya, GlusterFS version is 3.11.0, and we use the native client of GlusterFS. Please see the below information. $gluster v info vol Volume Name: vol Type: Distributed-Replicate Volume ID: d59bd014-3b8b-411a-8587-ee36d254f755 Status: Started Snapshot Count: 0 Number of Bricks: 90 x 2 = 180 Transport-type: tcp,rdma Bricks: ... Options Reconfigured: performance.force-readdirp: false

Hi Paul, A few questions: What type of volume is this and what client protocol are you using? What version of Gluster are you using? Regards, Nithya On 28 December 2017 at 20:09, Paul <flypen at gmail.com> wrote: > Hi, All, > > If I set cluster.readdir-optimize to on, the performance of "ls" is > better, but I find one problem. > > # ls > # ls > files.1

Hello, I saw that parallel-readdir was an experimental feature in GlusterFS version 3.10.0, became stable in version 3.11.0, and is now recommended for small file workloads in the Red Hat Gluster Storage Server documentation[2]. I've successfully enabled this on one of my volumes but I notice the following in the client mount log: [2018-01-23 10:24:24.048055] W [MSGID: 101174]

can you please test parallel-readdir or readdir-ahead gives disconnects? so we know which to disable parallel-readdir doing magic ran on pdf from last year https://events.static.linuxfound.org/sites/events/files/slides/Gluster_DirPerf_Vault2017_0.pdf -v On Thu, Jan 25, 2018 at 8:20 AM, Alan Orth <alan.orth at gmail.com> wrote: > By the way, on a slightly related note, I'm pretty

If "strdup (d->d_name)" fails with "i" > 0, then both "p" and "ret->guestfs_int_dirent_list_val" are non-null pointers, but the latter is no more valid (since "p" is the new realloc'ed buffer). Hence, trying to free both will access to invalid memory. Make sure to free only one of them, "p" if not null or

Hello, We are having performance problems trying to migrate our pop/imap servers to a new version. Our old servers are 4 debian lenny with 5GB of RAM running of XenServer VMs with kernel 2.6.32-4-amd64 and dovecot 1.1.16. New servers are 4 ubuntu 12.04 with dovecot 2.1.5 running on vmware vm with 6 cores and 16GB of RAM and kernel 3.2.0-24-generic. On both server we are using nfs 3 with

Dear Vlad, I'm sorry, I don't want to test this again on my system just yet! It caused too much instability for my users and I don't have enough resources for a development environment. The only other variables that changed before the crashes was the group metadata-cache[0], which I enabled the same day as the parallel-readdir and readdir-ahead options: $ gluster volume set homes

Hi, As many of you know, gluster suffers from pretty bad performance issues when there are lots of files. One way to at least attempt to improve performance is setting cluster.readdir-optimize to on. However, based on my recent tests (using Gluster 3.13.2), as well as tests of many others (like http://lists.gluster.org/pipermail/gluster-devel/2016-November/051417.html), there's a bug that

By the way, on a slightly related note, I'm pretty sure either parallel-readdir or readdir-ahead has a regression in GlusterFS 3.12.x. We are running CentOS 7 with kernel-3.10.0-693.11.6.el7.x86_6. I updated my servers and clients to 3.12.4 and enabled these two options after reading about them in the 3.10.0 and 3.11.0 release notes. In the days after enabling these two options all of my

--- daemon/devsparts.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/daemon/devsparts.c b/daemon/devsparts.c index b89682c..e9c5e8f 100644 --- a/daemon/devsparts.c +++ b/daemon/devsparts.c @@ -40,7 +40,6 @@ foreach_block_device (block_dev_func_t func) int size = 0, alloc = 0; DIR *dir; - struct dirent *d; int err = 0; dir = opendir

I'm looking for comments on what to return from readdir in DL or DX. Currently, the data in DL is misaligned (patch coming soon, along with at least two more) but it also got me thinking about the fact that some filesystems, I believe, actually store st_mode directly in the filesystem. I'm thinking that using DX to return st_mode may prove more useful in the long run than just returning