similar to: btrfs and git-reflog

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

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

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 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: >

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,

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,

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. ? >

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.

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

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

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. ? > I will have a look at the wireshark trace and see if I can spot anything > obvious there. > I'm not an expert on this, but as far?as I know NFS isn't fully POSIX >

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

Hello. I am continuing my tests of BtrFS under a practical workload. Recently an incorrect poweroff (or maybe a small bug in BtrFS) caused a small data loss. The actual damage was non-existent. I used old branch, so maybe the relevant code is already improved. 1. Why btrfsck says "bad block" on that partition? What does it mean? My fist reaction was to use badblocks. It found no

I was flipping through the code recently and noticed that we still have the double whammy of allocating dir entry positions with parent_dir->counter++ and that weird setting of f_pos to 2^31-1. So after enough creates (and deletes :)) in a directory we end up with an entry item whose key is past that value. f_pos gets rewound instead of being set to that magical EOF. readdir() gets stuck

If add_string_nodup fails free the passed string instead of leaking it, as that string would have been owned by the stringbuf. Adapt few places to this behaviour. --- daemon/btrfs.c | 4 +--- daemon/devsparts.c | 8 ++++---- daemon/guestfsd.c | 1 + 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/daemon/btrfs.c b/daemon/btrfs.c index 9b52aa8..d70565a 100644 ---

Hello everyone, Btrfs v0.10 is now available for download from: http://oss.oracle.com/projects/btrfs/ Btrfs is still in an early alpha state, and the disk format is not finalized. v0.10 introduces a new disk format, and is not compatible with v0.9. The core of this release is explicit back references for all metadata blocks, data extents, and directory items. These are a crucial building

Hello everyone, Btrfs v0.10 is now available for download from: http://oss.oracle.com/projects/btrfs/ Btrfs is still in an early alpha state, and the disk format is not finalized. v0.10 introduces a new disk format, and is not compatible with v0.9. The core of this release is explicit back references for all metadata blocks, data extents, and directory items. These are a crucial building

Jason Kim <jasonwkim at google.com> writes: > I believe git has a similar system for maintaining "branches of patches"  A pointer/tutorial on how to do this would be most welcome. -Dave