November 2020 - Support - Nfs Ganesha List Archives

by David Hansen

Hi Ganesha support, There are more general questions. I have a client reporting that mounted via linux hosts he sometimes is not able to see the contents. Logging on to the Ganesha server on the local dir does show them however. I was wondering if someone could point me in the right direction for possible caching options to throw in the mount to make sure the client cach is up to date? Some things we've tried: - We tried umounting /dataBA on the VM and mounting again, didn't help - We rebooted the VM, didn't help - We checked VAS info for user on nfs server and VM, looked ok. Here we see we can cd into a directory (redacted6) that doesn't show up in ls. We thought maybe touching a file would force a cache update or something. [user6@b5c06 redacted4]$ cd redacted5/ [user6@b5c06 redacted5]$ ls afile [user6@b5c06 redacted5]$ ls -lh total 0 -rw-------. 1 user67 hpc.default 0 Nov 2 23:10 afile [user6@b5c06 redacted5]$ rm afile [user6@b5c06 redacted5]$ ls [user6@b5c06 redacted5]$ cd redacted6 [user6@b5c06 redacted6]$ ls 0-15ft 10ft 15ft 17-30ft 25ft 5ft [user6@b5c06 redacted6]$ cd .. [user6@b5c06 redacted5]$ ls Any pointers or insight would be fantastic. Thanks -- David Hansen WekaIO davidh(a)weka.io *•* https://www.weka.io/ <https://www.weka.io/?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_...> The World's Fastest File System <https://www.weka.io/promo/2020-10-esg-validation-paper/?utm_source=WiseSt...>

3 years, 5 months

3
8
0 / 0

git clone fails on nfs4 export

by f.stolte＠fz-juelich.de

I am using ganesha 3.3 to export the ceph filesystem via nfs4. Using git clone on a mounted nfs4 export i get the errors showing below. In my research i found a similar bug in ganesha (which was fixed) but related to the glusterfs FSAL (i am using the ceph FSAL). Is there a solution for this problem like setting parameters in config or do i need to report a bug? Error: $ git clone https://github.com/buckyroberts/Viberr.git Klone nach 'Viberr' ... remote: Enumerating objects: 77, done. remote: Total 77 (delta 0), reused 0 (delta 0), pack-reused 77 Empfange Objekte: 100% (77/77), 7.23 MiB | 7.35 MiB/s, Fertig. fatal: kann /home/f.stolte/Viberr/.git/objects/pack/tmp_pack_BytDsf nicht öffnen: Keine Berechtigung fatal: index-pack fehlgeschlagen Export: EXPORT { Export_Id = 1; Attr_Expiration_Time = 0; Path = "/vols/its/its_linusers"; Pseudo = "/its_linusers"; # Export to localhost for monitoring Client { Access_type = MDONLY_RO; Clients = 127.0.0.1; } Client { Clients = 10.0.0.1; Access_type = RW; Squash = No_Root_Squash; } Client { Clients = 10.0.0.1/23; Access_type = RW; } Protocols = 3,4; FSAL { Name = Ceph; User_ID = "admin"; } }

3 years, 5 months

2
1
0 / 0

git clone fails on NFS4 exports using FSAL Ceph

by f.stolte＠fz-juelich.de

Hello, i am exporting the ceph filesystem via FSAL Ceph on ganesha 3.3. When i try to do a "git clone <some_repository>" on an export mounted via NFS4 i get the following error: $ git clone https://github.com/buckyroberts/Viberr.git Klone nach 'Viberr' ... remote: Enumerating objects: 77, done. remote: Total 77 (delta 0), reused 0 (delta 0), pack-reused 77 Empfange Objekte: 100% (77/77), 7.23 MiB | 7.13 MiB/s, Fertig. fatal: kann /home/f.stolte/Viberr/.git/objects/pack/tmp_pack_gi8Eex nicht öffnen: Keine Berechtigung fatal: index-pack fehlgeschlagen While researching this issue, i found a similar bug in ganesha, but it was related to the gluster FSAL. While exporting the mounted cephfilesystem with the VFS FSAL, git clone works fine. But VFS does not respect the directory quota we set like the ceph FSAL, so this way is not an option. Can i fix this issue with a config parameter or do i need to report a bug for the ganesha ceph FSAL?

3 years, 5 months

3
7
0 / 0

'ganesha_mgr display_export - client not listed

by Billich Heinrich Rainer (ID SD)

Hello, Some nfsv4 client of ganesha does not show up in the output of 'ganesha_mgr display_export'. The client has an active mount, but also shows some nfs issues, some commands did hang, the process just stays in state D (uninterruptible sleep) according to 'ps', but not the whole mount. I just wonder if the client's IP should always show up in the output of display_export once the client did issue a mount call and if the absence indicates that something is broken. Gutr,gut, Putting it the other way round: When is a client listed in the output of display_export and when is it removed from the list? We do collect more debug data, this is just something that catched my eye. Thank you, Heiner We run ganesha 2.7.5-ibm058.05 on a spectrum scale system on RedHat 7.7. I crosspost to the gpfsug mailing list. -- ======================= Heinrich Billich ETH Zürich Informatikdienste Tel.: +41 44 632 72 56 heinrich.billich(a)id.ethz.ch ======================== # ganesha_mgr display_export 37 Display export with id 37 export 37: path = /xxxx/yyy, pseudo = /xxx/yyy , tag = /xxx/yyy Client type, CIDR version, CIDR address, CIDR mask, CIDR proto, Anonymous UID, Anonymous GID, Attribute timeout, Options, Set a.b.c.198/32, 0, 0, 255, 1, 4294967294, 4294967294, 0, 1126195680, 1081209831 a.b.c.143/32, 0, 0, 255, 1, 4294967294, 4294967294, 0, 1126195680, 1081209831 a.b.c.236/32, 0, 0, 255, 1, 4294967294, 4294967294, 0, 1126195680, 1081209831 a.b.c.34/32, 0, 0, 255, 1, 4294967294, 4294967294, 0, 1126195680, 1081209831 a.b.c.70/32, 0, 0, 255, 1, 4294967294, 4294967294, 0, 1126195680, 1081209831 a.b.c.71/32, 0, 0, 255, 1, 4294967294, 4294967294, 0, 1126195680, 1081209831 *, 0, 0, 0, 0, 4294967294, 4294967294, 0, 1126187490, 1081209831

3 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

Support November 2020