NFS reexport works, still stat-prefetch issues, -s problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wow, you guys seem to be having a real bugfixathon in your tla repository; there were an impressive list of patches this week!

I grabbed the latest tla update a few hours ago and tried it out. My observations:

1) NFS reexport seems to work! Glusterfsd no longer blows up to an enormous size and then dies. It's completely happy, so far.

2) Stat-prefetch is still glitchy. I noticed the following when doing a du of a subdirectory that was NFS reexported:

du -sk * |sort -n
du: `rkhunter-install/lib/rkhunter/docs/lustre': No such file or directory
du: `rkhunter-install/lib/rkhunter/docs/lost+found': No such file or directory
du: `rkhunter-install/lib/rkhunter/docs/system': No such file or directory
du: `rkhunter-install/lib/rkhunter/docs/internal': No such file or directory
du: `solaris/openldap-2.1.29/include/lustre': No such file or directory
du: `solaris/openldap-2.1.29/include/lost+found': No such file or directory
du: `solaris/openldap-2.1.29/include/system': No such file or directory
du: `solaris/openldap-2.1.29/include/internal': No such file or directory
du: `solaris/openldap-2.1.29/tests/progs/lustre': No such file or directory
du: `solaris/openldap-2.1.29/tests/progs/lost+found': No such file or directory
du: `solaris/openldap-2.1.29/tests/progs/system': No such file or directory
du: `solaris/openldap-2.1.29/tests/progs/internal': No such file or directory
du: `solaris/openldap-2.1.29/doc/devel/lustre': No such file or directory
du: `solaris/openldap-2.1.29/doc/devel/lost+found': No such file or directory
du: `solaris/openldap-2.1.29/doc/devel/system': No such file or directory
du: `solaris/openldap-2.1.29/doc/devel/internal': No such file or directory

...and then it gave presumably normal du output. lustre, lost+found, system, and internal are the top-level directories in the filesystem and definitely don't exist in the area that was being du'ed.

Further, after unmounting the NFS, I attempted the same du on the machine that had reexported the filesystem, and its glusterfs promptly died.

Repeating these tests without stat-prefetch, everything was perfect!

3) When doing glusterfs -s to a different machine to retrieve the spec file, it now fails. A glusterfs -s to the local machine succeeds. It looks like a small buglet was introduced in the -s support.

I noticed that there were a lot of io-threads fixes this week. I assume, however, that none of them fix the related mtime issue, so I haven't tried io-threads.

In any case, with NFS reexport and our particular subset of modules all appearing to be stable, it looks like we're going to go to the next stage of testing in our environment, with some internal deployments for our own usage.

Many thanks,

Brent




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux