NFS Locking issues with FreeBSD

We're using several FreeBSD servers which require working NFS locking. Mounting a share with file locking from another FreeBSD NFS server is no problem, so lockd and statd seem to work fine on the clients.

Is there a known problem with NFS locking and FreeBSD? And if so, how can I fix it? I cannot circumvent locking, because that will almost unavoidably cause data corruption.

I've read some rather old posts about problems between FreeBSD and Linux, Linux seems to support "locking cookies" of only 8 bytes (it seems that up to 1 KByte should be acceptable), whereas FreeBSD uses 16 bytes since version 5.1. I don't know if this has been fixed in more recent Linux implementations and I also don't know if it applies to open-e DSS.

We are using Debian based Linux Servers which we mount NFS shares on. We have the same problem that the file locking is not working.
Talking to the vendor support, this is a known bug to Open-E and they are working on to fix it within the next software updates.

Sorry posting first reply before searching the software update section:

[2008-05-05]
Open-E DSS update ver. 5.00 up46 build 3084

"Fixed:
- NFS locking file does not work"

Hi,

We encountered the file locking issue with Open-e ver. 5.00 released on 17 May 2008.
The NFS client runs on SUSE Linux 10.

Were your NFS file locking issues resolved?

Thanks!

/CS

Quote:

---

Originally Posted by terrasys

Sorry posting first reply before searching the software update section:

[2008-05-05]
Open-E DSS update ver. 5.00 up46 build 3084

"Fixed:
- NFS locking file does not work"

---

Unfortunately we're still experiencing NFS locking issues with the lastest DSS code (5.0.DB47000000.3216) :mad: :

Our user's home directories are mounted via NFS by the user's workstations (currently openSuSE 11.0). Both Firefox 3.0 and Eclipse cannot store profiles resp. workspaces inside the home directories due to locking issues.

Setting the NFS "insecure locks" flag for the shares does not make any difference (although I haven't tested rebooting the DSS after setting that flag).

Does anyone have such a setup working reliably? We currently have to sync the (NFS-based) profiles with copies on file systems local to each workstation before starting and after stopping Firefox, rendering the idea of NFS-based home directories nearly useless.

With regards,
Jens

Hello Jen,
Please provide us with your mounting string? You may also send your logs (Status->Hardware) to our support e-mail. support@open-e.com

Thanks
SJ

Quote:

---

Originally Posted by Sh-J

Hello Jen,
Please provide us with your mounting string? You may also send your logs (Status->Hardware) to our support e-mail. support@open-e.com

Thanks
SJ

---

SJ,

Thanks fpr looking into this.

I will provide the information on Friday - I'm not on location right now.

With regards
Jens

Quote:

---

Originally Posted by Sh-J

Hello Jen,
Please provide us with your mounting string? You may also send your logs (Status->Hardware) to our support e-mail. support@open-e.com

Thanks
SJ

---

Hello SJ,

I'm sorry for the delay, it was a rather busy Friday :-/ Here's the corresponding output of "/bin/mount":
ourSANserver:/share/someuser on /home/someuser type nfs (rw,nosuid,nodev,hard,intr,addr=<IP-Addr removed for security reasons>,nfsvers=3,proto=tcp,mountproto=udp)

The mount is done via autofs, the map entry has the following string
-fstype=nfs,hard,intr,nodev,nosuid ourSANserver:/share/&

Should I try some other options before sending in the logs? If I mail the logs to you, should I include any specific reference in the subject line or mail body?

With regards,

Jens

Dear Jen,

I would like to look at the logs. Please send it and in the text body copy the description of the issue so we can keep tracking and everybody see the whole picture.

Regards,
SJ

Quote:

---

Originally Posted by Sh-J

Dear Jen,

I would like to look at the logs. Please send it and in the text body copy the description of the issue so we can keep tracking and everybody see the whole picture.

Regards,
SJ

---

SJ,

after we "forced an unexpected reboot" (UPS broke down) this night and had the system power up from nil, NFS locking works :rolleyes: . I do believe we had reboots after changing the settings (and locking didn't work), but no power-offs.

Regards,

Jens

@jmo: I have the exact same problem... only in reverse.

When upgrading to OS X 10.5 (from 10.4) we got problems with locking. At first I thought this was a OS X issue, but after upgrading the DSS to 5.0 DB47 build 3216 all of a sudden it worked.

Yesterday I had to take the system down completely to change a 10GbE cable and when it came up again the locking issue was back.

I'll try to do a proper cold-start as soon as I can to see if I can restore the lock-functionality again.

It is a bit scary if the locking feature is random depending on your luck since we have the home directory of both mac's and a bunch of linux workstations mounted from the dss.


-atle

Dear Atle,

Please submit your logs to support@open-e.com with description of the problem. In this way testers can verify it and check the error.

Regards,
SJ

I restarted the server twice this morning, but unfortunately it didn't help.

Have mailed my logs to support so we'll see what they find out.

-atle

Dear Atle,

Thanks for submitting the logs. We are going to look at them and get back to you ASAP.

Regards,
SJ

Dear all,

we have the same problems on or SOLARIS mounted DSS. As there are some users already waiting to go back to work, I would like to ask: Do you already know when an update will be available ?

Best regards.

@Koroljow:
As I understood it they are working on a fix, but they can't promise when it will be ready. We too have several systems, both servers and workstations, that we can't use because of this issue and if it's not fixed soon we have to consider some other distro instead of DSS.

-atle

@atle: Do you already have alterntives in your mind ? Most of today's RAIDS seem to work on OPEN-E or on (far too expensive) Netapp systems ...

Best regards,
Koroljow

@Koroljow: Ubuntu server 8.04 will probably do the trick for us. It supports our 3ware 9650SE-16ML card as well as all the network cards in the system. If that doesn't work as expected I'll probably go back to my favorite server-distro gentoo even though that one takes a bit more time to set up.

-atle

@atle: I have just received an update iso (in engineering state) for this problem from OPEN-E Munic. It seems that the official patch will be out something in between 2 weeks and 2 months. Have you tried to phone them, also ?

@Koroljow: I've been exchanging e-mails with support up until two weeks ago and they were supposed to let me know when they have a fix ready.

Let me know if the fix works and I'll bug them again :D

@atle: My management decided to wait for the patch, so I will not be able to test the engineering patch before. If you are interested in getting the iso, please let me know.

@Koroljow: I was offered a patch that should solve the issue, but with the drawback that all users would be set to "anonymous". If the patch you have doesn't have this issue I would love to test it out :)

If the patch didn't fix the problem, please contact us back.

Regards,
SJ

@atle: Please check your mails for my contact infos.

@Sh-J: As I just heard from atle, the engineering patch n20081031s.149_b3262 did not fix the problem.:confused:

I see this problem still as a no-go for our installation. When will OPEN-E release the final patch solving this issue ?

At least the next official update (within the next few days) will solve the nfs lock issue, as the associated engineering patch I tested runs fine on my machine.

Dear Koroljow & atle,

A new update DSS 5.0 build 3277 will have a fix for this NFS issue. It will be upload it on our server in few days.

Regards,
SJ