similar to: Missing Files/Missing Folders from an NFS Share

I'm trying to get to the bottom of where the normal directory functions differ in results for block storage compared to NFS. I created a short c script to look at the offsets generated for the directory when block storage backed in comparison to NFS backed. block storage backed are always positive: File: 5050, Offset: 9213006461214587617 File: 6567, Offset: 9218690536865144001 File: 4033,

On Thu, Feb 16, 2023 at 08:46:26PM +0100, Conor Armstrong wrote: > I'm trying to get to the?bottom of where the normal directory functions > differ in results for block storage compared to NFS.? > I created a short c script to look at the offsets generated for the > directory when block storage backed in comparison to NFS backed.? > block storage backed are always

Forgot to CC: the list. ----- Forwarded message from Jeremy Allison <jra at samba.org> ----- Cc: jra at samba.org Subject: Re: [Samba] Missing Files/Missing Folders from an NFS Share On Wed, Feb 15, 2023 at 08:06:28PM +0100, Conor Armstrong wrote: > Rowland & Jeremy - thanks for this! > I built a copy of the latest version from github 4.19 and same issue > arises. ? >

Alternately, we could possibly modify the dptr_TellDir function to set a flag somewhere if it ever returns a negative offset. Then any calls to dptr_SeekDir checks if the flag is set and does a slower approach of a RewindDir and then multiple ReadDir & TellDir calls until we get the matching offset. If flag is not set then go with the normal SeekDir call??? On Fri, 17 Feb 2023 at 00:40,

I was just playing with git 1.5.3.8 and btrfs 0.11, and I noticed something odd. If I prepare a very simple repository: $ mkdir foo $ cd foo $ git init Initialized empty Git repository in .git/ $ echo hi > blort $ git add . $ git commit -m create Created initial commit 4ae9415: create 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 blort and then

Ok, starting to make sense now. In order to fix it.... I note that the lower level calls are wrapped in dir.c - eg dptr_SeekDir(...) wraps SeekDir(...) this might allow for some code to use array indexes instead of NFS cookies as noted by Chris Chilvers here for the 3.10 kernel: https://lore.kernel.org/all/CAAmbk-e-YQAPo6QyNB0aJyc9qzUShmEC+x5eTR7wqp1ABWADsg at mail.gmail.com/T/ > On the

On Fri, Feb 17, 2023 at 12:40:25AM +0100, Conor Armstrong wrote: > Ok, starting to make sense now.? In order to fix it.... > I note that the lower level calls are wrapped in dir.c - eg > dptr_SeekDir(...) wraps SeekDir(...) > this might allow for some code to use array indexes instead of NFS cookies > as noted by Chris Chilvers here for the 3.10 kernel: >

I think it has a lot to do with telldir on an NFS share returning a cookie that is supposed to be unique rather than an actual offset. Problem is, that cookie is stored as a 31bit hash which can then end up as a negative signed offset in Samba which is not handled correctly. The cookies are not necessarily consecutive as you move through a directory. On Mon, 27 Feb 2023 at 19:00, Jeremy Allison

On Mon, Feb 27, 2023 at 08:01:40PM +0100, Conor Armstrong wrote: > I think it has a lot to do with telldir on an NFS share returning a cookie > that is supposed to be unique rather than an actual offset. Problem is, > that cookie is stored as a 31bit hash which can then end up as a negative > signed offset in Samba which is not handled correctly. The cookies are not >

Hello, I have a problem with directories that contain more than 10000 entries (Ubuntu 8.04.1) or with more than 70000 entries (RHEL 5.2). If you use readdir(3) or readdir64(3) you get one entry twice, with same name and inode. Some analyzing showed that disabling dir_index solves this problem, but I think that this is a bug in the ext3 code, as no other file-system shows this behavior.

Hi, A stupid flat directory /tmp holding 5 millon files, the directory locates on a ext3 file system with dir_index feature turned on. The running Linux are FC4 and FC5. The files are just directly under /tmp, not in any subdirectories -- they are results of mis-operations of users. Then a 'ls' or 'find' command will take one hour to finish, a lot of other applications on

Jeremy, I think we found the part of source where the problem resides: smbd/trans2.c +1444 for (i=0;(i<maxentries) && !finished && !out_of_space;i++) { +1445 BOOL got_exact_match = False; +1446 +1447 /* this is a heuristic to avoid seeking the dirptr except when +1448 absolutely necessary. It allows for

Thanks for the patch, unfortunately when I installed it I had a lot more files missing from the directory listing and I have not taken much time to look at why. But it certainly is the cast that off_t on the IRIX box is 8 bytes in the current OS, however the compilers seem to convert the long values properly so long as overflow does not occur. Thanks to your suggestion on looking at the

Since the d_off in the first dirent for "." (that originates from the 4th argument "offset" of filldir() for the 2nd dirent for "..") is wrongly assigned in btrfs_real_readdir(), telldir returns same offset for different locations. | # mkfs.btrfs /dev/sdb1 | # mount /dev/sdb1 fs0 | # cd fs0 | # touch file0 file1 | # ../test | telldir: 0 | readdir: d_off = 2,

In a directory with approximately 6000 files, several files are missing on the Windows side. If I check the directory on Unix (AIX) they are all there. As far as I can see there's nothing strange with this files en I can't see any connection between the missing files. It looks like it's randomly. A few examples of missing files: FAKTREF.10062005.16 (See debug information)

By the way, there is nothing special about an AWS EFS share as far as I can see. It is just basically an NFS share. The answer some others were saying about Samba sharing the folder out from the NFS server isn?t possible. In AWS there is no access to the server behind EFS other than the NFS share itself. EFS has to be mounted as NFS. No other protocols are supported (eg CIFS or AFS). Anyway the

Hello, I have a Samba 3.0.24 server running on a NetBSD 3.1 (i386) box, which has been very reliable for a long time, but recently started to occasionally show the following error on PC's connected to it running XP Pro and AutoDesk (AutoCAD) files: z:\ is not available Not enough storage is available to process this command log.smbd shows this when it happens : [2007/06/08 10:01:50, 0]

Ok. Just tested from a local share... Was able to create a empty folder and delete from Windows client without issue. So definitely NFS related. On Fri, Mar 17, 2023, 2:53 PM Rowland Penny via samba <samba at lists.samba.org> wrote: > > > On 17/03/2023 18:46, Jeremy Allison via samba wrote: > > > > OK, almost certainly it's the NFS mount causing the problem.

We have Win98 DOS (4.11.2222) clients that exhibit behaviors thought to have been corrected. They are running the MS-CLIENT redirector. 3.0.11 will do a directory listing correctly and show all entries in upper case. 3.0.14a gets stuck in a dir loop with the client and displays non-mangled names in lower case. 3.0.20rc2 gets stuck in a dir loop with the client and displays all entries in upper

On Thu, Aug 06, 2020 at 09:23:46PM -0500, Eric Blake wrote: > + if (!filename == !directory) { A bit tricksy. In plugins/nbd/nbd.c I used: int c = !!sockname + !!hostname + !!uri + (command.size > 0) + (socket_fd >= 0) + !!raw_cid; /* Check the user passed exactly one connection parameter. */ if (c > 1) { nbdkit_error ("cannot mix Unix ‘socket’, TCP