hi,
i have come across a weird autocomplete issue i assume it is related to
btrfs.
let`s have some dirs:
/non-btrfs-mount
./linux
./testdir
/brtfs-mount
./linux
./testdir
now, if i do "cd t<tab>" in /non-btrfs-mount, "t"
autocompletes to "testdir"
same for l<tab>inux - bash autocompletes as expected.
now, the weird thing is, that on /btrfs-mount this behaves different.
autocompletion for testdir works, but not for linux dir. weird.
can someone reproduce this ?
i`m on opensuse 11.1 with 2.6.27.8-1-default and latest btrfs-unstable from
git.
regards
roland
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote:> i have come across a weird autocomplete issue i assume it is related to > btrfs. > > let`s have some dirs: > > /non-btrfs-mount > ./linux > ./testdir > > /brtfs-mount > ./linux > ./testdir > > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir" > same for l<tab>inux - bash autocompletes as expected. > > now, the weird thing is, that on /btrfs-mount this behaves different. > > autocompletion for testdir works, but not for linux dir. weird. > > can someone reproduce this ?Open another shell, find the bash process pid of the first shell with: ps afx and do: strace -p <pid> Go back to the first shell, hit <tab>, and the trace should show what''s going on. You see a significant difference there? Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote: > > i have come across a weird autocomplete issue i assume it is related to > > btrfs. > > > > let`s have some dirs: > > > > /non-btrfs-mount > > ./linux > > ./testdir > > > > /brtfs-mount > > ./linux > > ./testdir > > > > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir" > > same for l<tab>inux - bash autocompletes as expected. > > > > now, the weird thing is, that on /btrfs-mount this behaves different. > > > > autocompletion for testdir works, but not for linux dir. weird. > > > > can someone reproduce this ? > > Open another shell, find the bash process pid of the first shell with: > ps afx > and do: > strace -p <pid> > Go back to the first shell, hit <tab>, and the trace should show > what''s going on. You see a significant difference there?ok, here we go (i hope i did not cut important parts). i don`t see the real issue, but i did another interesting finding - see below bad (cd l<tab>): open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=18, st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, st_ctime=2008/12/16-21:32:37}) = 0 getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 104 _llseek(3, 3, [3], SEEK_SET) = 0 getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 32 close(3) = 0 write(2, "\7", 1) = 1 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 good (cd t<tab>): open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=18, st_atime=2008/12/16-21:38:13, st_mtime=2008/12/16-21:38:11, st_ctime=2008/12/16-21:38:11}) = 0 getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 104 _llseek(3, 3, [3], SEEK_SET) = 0 getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 32 close(3) = 0 stat64("test", {st_dev=makedev(0, 19), st_ino=257, st_mode=S_IFDIR|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2008/12/16-21:15:29, st_mtime=2008/12/16-21:15:29, st_ctime=2008/12/16-21:15:29}) = 0 stat64("test", {st_dev=makedev(0, 19), st_ino=257, st_mode=S_IFDIR|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2008/12/16-21:15:29, st_mtime=2008/12/16-21:15:29, st_ctime=2008/12/16-21:15:29}) = 0 write(2, "est/", 4) = 4 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 and now, after adding a file to that dir with "touch abcd", for my curiousity this makes "cd l<tab>" work again. open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=26, st_atime=2008/12/16-21:34:45, st_mtime=2008/12/16-21:34:44, st_ctime=2008/12/16-21:34:44}) = 0 getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=258, d_off=17, d_type=DT_DIR, d_reclen=32, d_name="linux"} {d_ino=272, d_off=9223372036854775807, d_type=DT_REG, d_reclen=24, d_name="abcd"}}, 4096) = 128 _llseek(3, 17, [17], SEEK_SET) = 0 getdents64(3, {{d_ino=272, d_off=9223372036854775807, d_type=DT_REG, d_reclen=24, d_name="abcd"}}, 4096) = 24 close(3) = 0 stat64("linux", {st_dev=makedev(0, 19), st_ino=258, st_mode=S_IFDIR|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2008/12/16-21:15:33, st_mtime=2008/12/16-21:15:33, st_ctime=2008/12/16-21:15:33}) = 0 stat64("linux", {st_dev=makedev(0, 19), st_ino=258, st_mode=S_IFDIR|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2008/12/16-21:15:33, st_mtime=2008/12/16-21:15:33, st_ctime=2008/12/16-21:15:33}) = 0 write(2, "inux/", 5) = 5 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 regards roland _______________________________________________________________________ Täglich 1.000.000 Euro gewinnen! Jetzt kostenlos WEB.DE MillionenKlick spielen! https://millionenklick.web.de/?mc=mail@footer.mklick@home -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 16, 2008 at 21:46, <devzero@web.de> wrote:>> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote: >> > i have come across a weird autocomplete issue i assume it is related to >> > btrfs. >> > >> > let`s have some dirs: >> > >> > /non-btrfs-mount >> > ./linux >> > ./testdir >> > >> > /brtfs-mount >> > ./linux >> > ./testdir >> > >> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir" >> > same for l<tab>inux - bash autocompletes as expected. >> > >> > now, the weird thing is, that on /btrfs-mount this behaves different. >> > >> > autocompletion for testdir works, but not for linux dir. weird. >> > >> > can someone reproduce this ? >> >> Open another shell, find the bash process pid of the first shell with: >> ps afx >> and do: >> strace -p <pid> >> Go back to the first shell, hit <tab>, and the trace should show >> what''s going on. You see a significant difference there? > > > ok, here we go (i hope i did not cut important parts). > i don`t see the real issue, but i did another interesting finding - see below > > > bad (cd l<tab>): > > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=18, st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, st_ctime=2008/12/16-21:32:37}) = 0 > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 104 > _llseek(3, 3, [3], SEEK_SET) = 0 > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 32On Tue, Dec 16, 2008 at 22:26, <devzero@web.de> wrote:> i assume it has something to do with the large value for d_off of the last dirent ?Looks like, 9223372036854775807 is just LLONG_MAX. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:> On Tue, Dec 16, 2008 at 21:46, <devzero@web.de> wrote: > >> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote: > >> > i have come across a weird autocomplete issue i assume it is related to > >> > btrfs. > >> > > >> > let`s have some dirs: > >> > > >> > /non-btrfs-mount > >> > ./linux > >> > ./testdir > >> > > >> > /brtfs-mount > >> > ./linux > >> > ./testdir > >> > > >> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to "testdir" > >> > same for l<tab>inux - bash autocompletes as expected. > >> > > >> > now, the weird thing is, that on /btrfs-mount this behaves different. > >> > > >> > autocompletion for testdir works, but not for linux dir. weird. > >> > > >> > can someone reproduce this ? > >> > >> Open another shell, find the bash process pid of the first shell with: > >> ps afx > >> and do: > >> strace -p <pid> > >> Go back to the first shell, hit <tab>, and the trace should show > >> what''s going on. You see a significant difference there? > > > > > > ok, here we go (i hope i did not cut important parts). > > i don`t see the real issue, but i did another interesting finding - see below > > > > > > bad (cd l<tab>): > > > > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 > > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=18, st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, st_ctime=2008/12/16-21:32:37}) = 0 > > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 104 > > _llseek(3, 3, [3], SEEK_SET) = 0 > > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"}}, 4096) = 32 > > On Tue, Dec 16, 2008 at 22:26, <devzero@web.de> wrote: > > i assume it has something to do with the large value for d_off of the last dirent ? > > Looks like, 9223372036854775807 is just LLONG_MAX.I can not reproduce that (on openSUSE 11.1). I also don''t see the _llseek() calls. open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 fstat(3, {st_dev=makedev(0, 18), ... getdents64(3, { {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"} {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"} {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"} {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"} {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, d_name="linux"} }, 4096) = 176 getdents64(3, {}, 4096) = 0 close(3) This is with today''s git kernel and today''s standalone btrfs unstable. You are using the distro kernel and compile the standalone btrfs module? Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote: >> On Tue, Dec 16, 2008 at 21:46, <devzero@web.de> wrote: >> >> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote: >> >> > i have come across a weird autocomplete issue i assume it is related >> >> > to >> >> > btrfs. >> >> > >> >> > let`s have some dirs: >> >> > >> >> > /non-btrfs-mount >> >> > ./linux >> >> > ./testdir >> >> > >> >> > /brtfs-mount >> >> > ./linux >> >> > ./testdir >> >> > >> >> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to >> >> > "testdir" >> >> > same for l<tab>inux - bash autocompletes as expected. >> >> > >> >> > now, the weird thing is, that on /btrfs-mount this behaves >> >> > different. >> >> > >> >> > autocompletion for testdir works, but not for linux dir. weird. >> >> > >> >> > can someone reproduce this ? >> >> >> >> Open another shell, find the bash process pid of the first shell with: >> >> ps afx >> >> and do: >> >> strace -p <pid> >> >> Go back to the first shell, hit <tab>, and the trace should show >> >> what''s going on. You see a significant difference there? >> > >> > >> > ok, here we go (i hope i did not cut important parts). >> > i don`t see the real issue, but i did another interesting finding - see >> > below >> > >> > >> > bad (cd l<tab>): >> > >> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 >> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, >> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, >> > st_size=18, st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, >> > st_ctime=2008/12/16-21:32:37}) = 0 >> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, >> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, >> > d_name=".."} {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, >> > d_name="test"} {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, >> > d_reclen=32, d_name="linux"}}, 4096) = 104 >> > _llseek(3, 3, [3], SEEK_SET) = 0 >> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, >> > d_reclen=32, d_name="linux"}}, 4096) = 32 >> >> On Tue, Dec 16, 2008 at 22:26, <devzero@web.de> wrote: >> > i assume it has something to do with the large value for d_off of the >> > last dirent ? >> >> Looks like, 9223372036854775807 is just LLONG_MAX. > > I can not reproduce that (on openSUSE 11.1). I also don''t see > the _llseek() calls.weird. no btrfs issue then !?> > open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 > fstat(3, {st_dev=makedev(0, 18), ... > getdents64(3, { > {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} > {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} > {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"} > {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"} > {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"} > {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"} > {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, > d_name="linux"} > }, 4096) = 176 > getdents64(3, {}, 4096) = 0 > close(3) > > This is with today''s git kernel and today''s standalone btrfs unstable. > > You are using the distro kernel and compile the standalone btrfs module?yes. to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory some days ago) linux:~ # bash -version GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. roland -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote:>> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote: >>> >>> On Tue, Dec 16, 2008 at 21:46, <devzero@web.de> wrote: >>> >> On Tue, Dec 16, 2008 at 20:37, Roland <devzero@web.de> wrote: >>> >> > i have come across a weird autocomplete issue i assume it is related >>> >> > >> > to >>> >> > btrfs. >>> >> > >>> >> > let`s have some dirs: >>> >> > >>> >> > /non-btrfs-mount >>> >> > ./linux >>> >> > ./testdir >>> >> > >>> >> > /brtfs-mount >>> >> > ./linux >>> >> > ./testdir >>> >> > >>> >> > now, if i do "cd t<tab>" in /non-btrfs-mount, "t" autocompletes to >>> >> > >> > "testdir" >>> >> > same for l<tab>inux - bash autocompletes as expected. >>> >> > >>> >> > now, the weird thing is, that on /btrfs-mount this behaves >> > >>> >> > different. >>> >> > >>> >> > autocompletion for testdir works, but not for linux dir. weird. >>> >> > >>> >> > can someone reproduce this ? >>> >> >>> >> Open another shell, find the bash process pid of the first shell with: >>> >> ps afx >>> >> and do: >>> >> strace -p <pid> >>> >> Go back to the first shell, hit <tab>, and the trace should show >>> >> what''s going on. You see a significant difference there? >>> > >>> > >>> > ok, here we go (i hope i did not cut important parts). >>> > i don`t see the real issue, but i did another interesting finding - see >>> > > below >>> > >>> > >>> > bad (cd l<tab>): >>> > >>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 >>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, > >>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18, >>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, > >>> > st_ctime=2008/12/16-21:32:37}) = 0 >>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > >>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."} >>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"} >>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32, >>> > d_name="linux"}}, 4096) = 104 >>> > _llseek(3, 3, [3], SEEK_SET) = 0 >>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > >>> > d_reclen=32, d_name="linux"}}, 4096) = 32 >>> >>> On Tue, Dec 16, 2008 at 22:26, <devzero@web.de> wrote: >>> > i assume it has something to do with the large value for d_off of the > >>> > last dirent ? >>> >>> Looks like, 9223372036854775807 is just LLONG_MAX. >> >> I can not reproduce that (on openSUSE 11.1). I also don''t see >> the _llseek() calls. > > weird. no btrfs issue then !? > >> >> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 >> fstat(3, {st_dev=makedev(0, 18), ... >> getdents64(3, { >> {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} >> {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} >> {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"} >> {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"} >> {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"} >> {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"} >> {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, >> d_name="linux"} >> }, 4096) = 176 >> getdents64(3, {}, 4096) = 0 >> close(3) >> >> This is with today''s git kernel and today''s standalone btrfs unstable. >> >> You are using the distro kernel and compile the standalone btrfs module? > > yes. > to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory > some days ago) > > linux:~ # bash -version > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) > Copyright (C) 2007 Free Software Foundation, Inc.That is still the same bash, the one you use is a 32bit version. Do you run a 32 bit kernel too? I could try that on a 32 bit box then. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2008-12-17 at 14:59 +0100, Kay Sievers wrote:> On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote: > >> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote: > >>> > >>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 > >>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, > > >>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18, > >>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, > > >>> > st_ctime=2008/12/16-21:32:37}) = 0 > >>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > > >>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."} > >>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"} > >>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32, > >>> > d_name="linux"}}, 4096) = 104 > >>> > _llseek(3, 3, [3], SEEK_SET) = 0 > >>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > > >>> > d_reclen=32, d_name="linux"}}, 4096) = 32 > >>> > >>> On Tue, Dec 16, 2008 at 22:26, <devzero@web.de> wrote: > >>> > i assume it has something to do with the large value for d_off of the > > >>> > last dirent ? > >>> > >>> Looks like, 9223372036854775807 is just LLONG_MAX. > >> > >> I can not reproduce that (on openSUSE 11.1). I also don''t see > >> the _llseek() calls. > > > > weird. no btrfs issue then !? > > > >> > >> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 > >> fstat(3, {st_dev=makedev(0, 18), ... > >> getdents64(3, { > >> {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} > >> {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} > >> {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"} > >> {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"} > >> {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"} > >> {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"} > >> {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, > >> d_name="linux"} > >> }, 4096) = 176 > >> getdents64(3, {}, 4096) = 0 > >> close(3) > >> > >> This is with today''s git kernel and today''s standalone btrfs unstable. > >> > >> You are using the distro kernel and compile the standalone btrfs module? > > > > yes. > > to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory > > some days ago) > > > > linux:~ # bash -version > > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) > > Copyright (C) 2007 Free Software Foundation, Inc. > > That is still the same bash, the one you use is a 32bit version. Do > you run a 32 bit kernel too? I could try that on a 32 bit box then.At least on my 32 bit box, tab completion works fine. But, the d_off of LLONG_MAX comes from btrfs_readdir(). Git had a feature where it would loop infinitely over a directory in some cases and this was my workaround. This should be fixed in git by now, so I can drop it if that really is causing problems in bash. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > linux:~ # bash -version > > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) > > Copyright (C) 2007 Free Software Foundation, Inc. > > That is still the same bash, the one you use is a 32bit version. Do > you run a 32 bit kernel too? I could try that on a 32 bit box then. > > Thanks, > Kay >yes, all 32bit. _______________________________________________________________________ Täglich 1.000.000 Euro gewinnen! Jetzt kostenlos WEB.DE MillionenKlick spielen! https://millionenklick.web.de/?mc=mail@footer.mklick@home -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 17, 2008 at 15:17, Chris Mason <chris.mason@oracle.com> wrote:> On Wed, 2008-12-17 at 14:59 +0100, Kay Sievers wrote: >> On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote: >> >> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote: >> >>> >> >>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 >> >>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, > >> >>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18, >> >>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, > >> >>> > st_ctime=2008/12/16-21:32:37}) = 0 >> >>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > >> >>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."} >> >>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"} >> >>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32, >> >>> > d_name="linux"}}, 4096) = 104 >> >>> > _llseek(3, 3, [3], SEEK_SET) = 0 >> >>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > >> >>> > d_reclen=32, d_name="linux"}}, 4096) = 32 >> >>> >> >>> On Tue, Dec 16, 2008 at 22:26, <devzero@web.de> wrote: >> >>> > i assume it has something to do with the large value for d_off of the > >> >>> > last dirent ? >> >>> >> >>> Looks like, 9223372036854775807 is just LLONG_MAX. >> >> >> >> I can not reproduce that (on openSUSE 11.1). I also don''t see >> >> the _llseek() calls. >> > >> > weird. no btrfs issue then !? >> > >> >> >> >> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 >> >> fstat(3, {st_dev=makedev(0, 18), ... >> >> getdents64(3, { >> >> {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} >> >> {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} >> >> {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"} >> >> {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"} >> >> {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"} >> >> {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"} >> >> {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, >> >> d_name="linux"} >> >> }, 4096) = 176 >> >> getdents64(3, {}, 4096) = 0 >> >> close(3) >> >> >> >> This is with today''s git kernel and today''s standalone btrfs unstable. >> >> >> >> You are using the distro kernel and compile the standalone btrfs module? >> > >> > yes. >> > to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory >> > some days ago) >> > >> > linux:~ # bash -version >> > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) >> > Copyright (C) 2007 Free Software Foundation, Inc. >> >> That is still the same bash, the one you use is a 32bit version. Do >> you run a 32 bit kernel too? I could try that on a 32 bit box then. > > At least on my 32 bit box, tab completion works fine.It works fine here too on 64 bit. I''ll try with openSUSE 11.1 on a 32bit box later tonight.> But, the d_off of > LLONG_MAX comes from btrfs_readdir(). Git had a feature where it would > loop infinitely over a directory in some cases and this was my > workaround.There are other filesystems doing the same, usually with 32bit int max instead of 64 bit int max, I guess that should work fine.> This should be fixed in git by now, so I can drop it if that really is > causing problems in bash.I''ll come back if I can reproduce it with the same environment Roland is using. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 17, 2008 at 15:46, Kay Sievers <kay.sievers@vrfy.org> wrote:> On Wed, Dec 17, 2008 at 15:17, Chris Mason <chris.mason@oracle.com> wrote: >> On Wed, 2008-12-17 at 14:59 +0100, Kay Sievers wrote: >>> On Wed, Dec 17, 2008 at 09:45, Roland <devzero@web.de> wrote: >>> >> On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote: >>> >>> >>> >>> > open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 >>> >>> > fstat64(3, {st_dev=makedev(0, 19), st_ino=256, st_mode=S_IFDIR|0555, > >>> >>> > st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, > st_size=18, >>> >>> > st_atime=2008/12/16-21:32:38, st_mtime=2008/12/16-21:32:37, > >>> >>> > st_ctime=2008/12/16-21:32:37}) = 0 >>> >>> > getdents64(3, {{d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > >>> >>> > d_name="."} {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, > d_name=".."} >>> >>> > {d_ino=257, d_off=3, d_type=DT_DIR, d_reclen=24, > d_name="test"} >>> >>> > {d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > d_reclen=32, >>> >>> > d_name="linux"}}, 4096) = 104 >>> >>> > _llseek(3, 3, [3], SEEK_SET) = 0 >>> >>> > getdents64(3, {{d_ino=258, d_off=9223372036854775807, d_type=DT_DIR, > >>> >>> > d_reclen=32, d_name="linux"}}, 4096) = 32 >>> >>> >>> >>> On Tue, Dec 16, 2008 at 22:26, <devzero@web.de> wrote: >>> >>> > i assume it has something to do with the large value for d_off of the > >>> >>> > last dirent ? >>> >>> >>> >>> Looks like, 9223372036854775807 is just LLONG_MAX. >>> >> >>> >> I can not reproduce that (on openSUSE 11.1). I also don''t see >>> >> the _llseek() calls. >>> > >>> > weird. no btrfs issue then !? >>> > >>> >> >>> >> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 >>> >> fstat(3, {st_dev=makedev(0, 18), ... >>> >> getdents64(3, { >>> >> {d_ino=260, d_off=2, d_type=DT_DIR, d_reclen=24, d_name="."} >>> >> {d_ino=256, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} >>> >> {d_ino=261, d_off=3, d_type=DT_REG, d_reclen=24, d_name="a"} >>> >> {d_ino=262, d_off=4, d_type=DT_REG, d_reclen=24, d_name="b"} >>> >> {d_ino=263, d_off=5, d_type=DT_REG, d_reclen=24, d_name="c"} >>> >> {d_ino=264, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="test"} >>> >> {d_ino=265, d_off=9223372036854775807, d_type=DT_DIR, d_reclen=32, >>> >> d_name="linux"} >>> >> }, 4096) = 176 >>> >> getdents64(3, {}, 4096) = 0 >>> >> close(3) >>> >> >>> >> This is with today''s git kernel and today''s standalone btrfs unstable. >>> >> >>> >> You are using the distro kernel and compile the standalone btrfs module? >>> > >>> > yes. >>> > to be honest, i`m slightly newer than 11.1 (did zypper dup to latest factory >>> > some days ago) >>> > >>> > linux:~ # bash -version >>> > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) >>> > Copyright (C) 2007 Free Software Foundation, Inc. >>> >>> That is still the same bash, the one you use is a 32bit version. Do >>> you run a 32 bit kernel too? I could try that on a 32 bit box then. >> >> At least on my 32 bit box, tab completion works fine. > > It works fine here too on 64 bit. I''ll try with openSUSE 11.1 on a > 32bit box later tonight. > >> But, the d_off of >> LLONG_MAX comes from btrfs_readdir(). Git had a feature where it would >> loop infinitely over a directory in some cases and this was my >> workaround. > > There are other filesystems doing the same, usually with 32bit int max > instead of 64 bit int max, I guess that should work fine. > >> This should be fixed in git by now, so I can drop it if that really is >> causing problems in bash. > > I''ll come back if I can reproduce it with the same environment Roland is using.I see the same issue on x86 32 bit, with the additional __llseek() between the getdents64(), and the last entry returned by readdir ignored. If I change the returned LLONG_MAX to LONG_MAX in inode.c, it all works fine, and the __llseek() disappears. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2008-12-17 at 23:15 +0100, Kay Sievers wrote:> > There are other filesystems doing the same, usually with 32bit int max > > instead of 64 bit int max, I guess that should work fine. > > > >> This should be fixed in git by now, so I can drop it if that really is > >> causing problems in bash. > > > > I''ll come back if I can reproduce it with the same environment Roland is using. > > I see the same issue on x86 32 bit, with the additional __llseek() > between the getdents64(), and the last entry returned by readdir > ignored. > > If I change the returned LLONG_MAX to LONG_MAX in inode.c, it all > works fine, and the __llseek() disappears.Ok, thanks I''ll work up a patch. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> I see the same issue on x86 32 bit, with the additional __llseek() > between the getdents64(), and the last entry returned by readdir > ignored.confirmed - it`s readdir which assumes 32bit. attached is a sample program which shows the issue on my system. if compiled with -D_FILE_OFFSET_BITS=64", the problem goes away. old posting from around 2001:>http://sourceware.org/ml/libc-alpha/2001-01/msg00216.html > >This is why everybody will have to compile programs with >_FILE_OFFSET_BITS=64. Did you ever notice that all GNU programs >already do this?as 32bit systems can use 64bit filesystems, i think btrfs is correct and bash is wrong, as it isn`t LFS aware. i think all 32bit stuff should be LFS aware, nowadays. to be exact, it`s not bash but readline library which comes with bash. bash configure script correctly checks for _FILE_OFFSET_BITS value, but readline configure script doesn`t. this explains why i could not reproduce the issue when i build bash without readline support. does it make sense to file a ticket at novell bugzilla ? regards roland linux:/btrfs # ls -ltr total 13 drwxrwxrwx 1 root root 0 Dec 16 22:44 test drwxrwxrwx 1 root root 1056 Dec 17 01:10 linux-2.6.27.8-1 drwxr-xr-x 1 root root 0 Dec 17 22:53 abc drwxr-xr-x 1 root root 0 Dec 19 00:48 bcd -rw-r--r-- 1 root root 443 Dec 19 01:15 example.c -rwxr-xr-x 1 root root 10962 Dec 19 01:15 a.out linux:/btrfs # ./a.out . .. linux-2.6.27.8-1 test abc bcd example.c readdir: Value too large for defined data type regards roland #include <stdio.h> #include <sys/types.h> #include <dirent.h> #include <errno.h> #include <string.h> #include <stdlib.h> int main( int argc, char *argv[] ) { DIR *pDIR; struct dirent *pDirEnt; pDIR = opendir("."); pDirEnt = readdir( pDIR ); while ( pDirEnt != NULL ) { printf( "%s\n", pDirEnt->d_name ); pDirEnt = readdir( pDIR ); if (errno) perror("readdir"); } closedir( pDIR ); } ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 19, 2008 at 01:59, <devzero@web.de> wrote:>> I see the same issue on x86 32 bit, with the additional __llseek() >> between the getdents64(), and the last entry returned by readdir >> ignored. > > confirmed - it`s readdir which assumes 32bit. > > attached is a sample program which shows the issue on my system. > > if compiled with -D_FILE_OFFSET_BITS=64", the problem goes away. > > old posting from around 2001: > >>http://sourceware.org/ml/libc-alpha/2001-01/msg00216.html >> >>This is why everybody will have to compile programs with >>_FILE_OFFSET_BITS=64. Did you ever notice that all GNU programs >>already do this? > > as 32bit systems can use 64bit filesystems, i think btrfs is correct and bash is wrong, > as it isn`t LFS aware. i think all 32bit stuff should be LFS aware, nowadays. > > to be exact, it`s not bash but readline library which comes with bash. > bash configure script correctly checks for _FILE_OFFSET_BITS value, but readline configure script doesn`t. > this explains why i could not reproduce the issue when i build bash without readline support. > > does it make sense to file a ticket at novell bugzilla ?Sure, would be good to have that fixed. Cc: kasievers@novell.com in the bug, and I will move it directly to the right guy. :) Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Sure, would be good to have that fixed. Cc: kasievers@novell.com in > the bug, and I will move it directly to the right guy. :)ok, just submitted. https://bugzilla.novell.com/show_bug.cgi?id=460560 regards roland> -----Ursprüngliche Nachricht----- > Von: "Kay Sievers" <kay.sievers@vrfy.org> > Gesendet: 19.12.08 02:27:34 > An: devzero@web.de > CC: "Chris Mason" <chris.mason@oracle.com>, "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org> > Betreff: Re: weird bash autocomplete issue> On Fri, Dec 19, 2008 at 01:59, <devzero@web.de> wrote: > >> I see the same issue on x86 32 bit, with the additional __llseek() > >> between the getdents64(), and the last entry returned by readdir > >> ignored. > > > > confirmed - it`s readdir which assumes 32bit. > > > > attached is a sample program which shows the issue on my system. > > > > if compiled with -D_FILE_OFFSET_BITS=64", the problem goes away. > > > > old posting from around 2001: > > > >>http://sourceware.org/ml/libc-alpha/2001-01/msg00216.html > >> > >>This is why everybody will have to compile programs with > >>_FILE_OFFSET_BITS=64. Did you ever notice that all GNU programs > >>already do this? > > > > as 32bit systems can use 64bit filesystems, i think btrfs is correct and bash is wrong, > > as it isn`t LFS aware. i think all 32bit stuff should be LFS aware, nowadays. > > > > to be exact, it`s not bash but readline library which comes with bash. > > bash configure script correctly checks for _FILE_OFFSET_BITS value, but readline configure script doesn`t. > > this explains why i could not reproduce the issue when i build bash without readline support. > > > > does it make sense to file a ticket at novell bugzilla ? > > Sure, would be good to have that fixed. Cc: kasievers@novell.com in > the bug, and I will move it directly to the right guy. :) > > Thanks, > Kay >_______________________________________________________________________ Sensationsangebot verlängert: WEB.DE FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K15039B7069a -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html