NFS/permissions/OpenOffice

Hi

Great fan of OpenSuSE. Long may it prosper :slight_smile:

I have recently upgraded to openSuSE 11.2. All the .odp files on my NFS server (SeagateBlack Armour) now take ages to open. They do eventually open, but it can be several minutes between the Open Office splash and the file appearing on my screen.

The same files, opened in exactly the same way, in SUSE 11.1 do not experience this long delay.

I have check the configurations in both my 11.1 and 11.2 and cannot see any difference. Of course, Open Office on 11.1 is at a slightly lower revision than 11.2. I dont know if this is a Open Office or network/NFS problem I am experiencing.

Any help would be most gratefully appreciated. Thanks

As OO is unaware of NFS I should think it is a network/NFS problem. Did you try to get to these files in another way, or are there non OO files on the NFS mount you can open to see if you experience the same sort of delay (you could even put there some simple files using an editor).

Hi Henk

Thanks for the fast reply.

Yes, in the process of tearing my hair out on this, I have tried many things. For example, creating a text file on the NFS server, opening it with gedit, making a few changes and saving back. All works fine with no delays.

I have also renamed the .odp file to a .zip and then used file roller to open and inspect the contents (as .odp files are simply zip archives). This works fine, no delays.

However, using Open Office to open the .odp, many minutes of delay :frowning: Also, the strange thing is, when the file finally does appear in OpenOffice, it’s marked as “read only” in Open Office, so I can’t make any changes to it :frowning:

Something really weird is happening on my SuSE 11.2 as none of this Open Office behavior is apparent in SuSE 11.1. I really can’t understand what’s going on.

I even tried to get the same version of Open Office I have on 11.1 (from the 11.1 install CD) and replace the Open Office on 11.2 with it. That was a complete disaster as the install process pointed up many inconsistencies with the dependencies during the install process :frowning:

Kind regards

Nigel.

Hi everyone,

After installing Wireshark to monitor the network traffic as I open one of my .odp files with OO, I see this:

78 17.825534 192.168.1.2 192.168.1.200 NLM V4 LOCK Call (Reply In 182) FH:0x60fd22ec svid:8 pos:0-0

and later in the sequence:

182 47.828346 192.168.1.200 192.168.1.2 NLM V4 LOCK Reply (Call In 78) NLM_DENIED_NOLOCKS

The first entry above corresponds to OO beginning to open the file, and 30 seconds later, the file actually opened in OO!

So I mounted the NFS exported directory with “-o nolock” and tried to open the file again. Hey presto! No delays in OO.

So couple of questions:

  1. Is the default behaviour of NFS in 11.1 and 11.2 different (as I never used -o nlock in 11.1, where everything was fine)

  2. I’m not 100% sure on the ramifications of -o nolock. I will read the man entry again to see if this is a safe thing to do

  3. Does anyone know if the Seagate Black Armour NAS server supports the NLM protocol - I assume not from the Wireshark messages? This being the case, I still can’t figure out why it is only OO that has the delay in opening my files

Kind regards

Nigel.

nigelha wrote:
> Hi Henk
>
> Thanks for the fast reply.
>
> Yes, in the process of tearing my hair out on this, I have tried many
> things. For example, creating a text file on the NFS server, opening it
> with gedit, making a few changes and saving back. All works fine with no
> delays.
>
> I have also renamed the .odp file to a .zip and then used file roller
> to open and inspect the contents (as .odp files are simply zip
> archives). This works fine, no delays.
>
> However, using Open Office to open the .odp, many minutes of delay :frowning:
> Also, the strange thing is, when the file finally does appear in
> OpenOffice, it’s marked as “read only” in Open Office, so I can’t make
> any changes to it :frowning:
>
> Something really weird is happening on my SuSE 11.2 as none of this
> Open Office behavior is apparent in SuSE 11.1. I really can’t understand
> what’s going on.
>
> I even tried to get the same version of Open Office I have on 11.1
> (from the 11.1 install CD) and replace the Open Office on 11.2 with it.
> That was a complete disaster as the install process pointed up many
> inconsistencies with the dependencies during the install process :frowning:

Use a hammer… that is, you can sometimes get hints about the issue
by running the application under strace.

strace -f ooimpress filename.odp

Yes… it will produce a LOT of stuff (and things will run slow, which
may mask what you’re looking for)…

Just an idea…

Hi Nigel,

I do understand that you did not write down all you testing in your first post, but sometimes people realy do not know where to start when they experience problems. For that case I offer the most obvious things ;).

I understand that about your hair, I am at an advantage here because I almost have none :frowning:

As I said earlier, OO is not aware of NFS or of any mountpoint whatsoever. The kernel hides this away from application programs. Now this is of course not new to you. Again a stupid question. You did test the other way around? I mean using OO on a non NFSed file?

Asyou explain it, it realy looks if OO is using a complete differrent place to work from.

Can you see if a lot of network traffic is going on during that file opening?

These remarks are only for keeping up your morale.

EDIT: I just see you have laid your fingers on something. Good work!

Hi cj

Brilliant, thanks for the suggestion.

I did what you suggested with the strace. At the point that OO delays (before presenting the open file) I see many 100s of the following groups of lines repeated in the trace output:

7102 22:40:35 writev(5, {“8\2\4\0\2\0\240\4\4\0\0\0\350\237:\0C\0\5\0\1\0\240\4\2\0\240\4\16\0\346\0”…, 72}, {NULL, 0}, {"", 0}], 3) = 72
7102 22:40:35 read(5, 0x60bd94, 4096) = -1 EAGAIN (Resource temporarily unavailable)
7102 22:40:35 read(5, 0x60bd94, 4096) = -1 EAGAIN (Resource temporarily unavailable)
7102 22:40:35 poll({fd=4, events=POLLIN}], 1, 50) = 0 (Timeout)
7102 22:40:35 poll({fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ({fd=5, revents=POLLOUT}])

Then, when OO has the file open and presented to me on the screen, the above repeated lines stop (and the rest of the trace continues).

Now I am surprised as when I search backwards in the trace for filedes #5, I see the following call:

7102 22:40:34 open("/usr/lib64/ooo3/program/sofficerc", O_RDONLY) = 5

So I am unsure what is happening here as filedes #5 is opened in RO mode yet writev is trying to write something to it?

Also /usr/lib64/ooo3/program/sofficerc is not on the NFS mount, so I am not sure why the return of -1 EAGAIN (Resource temporarily unavailable) is happening?

Can you make any further suggestions please, as I’d really like to get to the bottom of what is happening here.

Kind regards

Nigel.

Hi Henk

Again… your help is really appreciated.

I still have some hair left rotfl!

Yes, I did try to open a plain text file on the NFS mount with oowriter. Exactly the same happened - a long delay before OO returned to me with the file open in READONLY mode.

I also have many hundreds of files (.ods, .odp and .odt) on an ext3 partition on the local hard drive. There is absolutely no problems with these.

In fact… to stop myself being unproductive, I actually copy whole directories from the NFS mount to /home, edit them in /home and then copy the directories back to the NFS mount. Clearly, I recognise this is a terrible solution :wink:

When there is the delay, using Wireshark, I don’t see much network activity - i.e. during the “delay”. After the delay, and just before OO opens the file and presents it to me on my screen, I see the network traffic of the file being sent fron the NAS device to my computer.

Yes my friend… I have lots of morale. And I do appreciate your help. I’d really love to get to the bottom of whats going on here and why 11.1 and 11.2 are behaving so differently with the same files.

Kind regards

Nigel.

No, it looks like you might have skipped over another open, dup, or socket (yes, that returns a FD also) when searching backwards in the strace log for FD 5. FD 5 looks like a network socket, not a local file. Look again. EAGAIN would be no data to read and FD 5 is in non-blocking mode so the program continues to poll until some data arrives or it gives up.

Hi Ken

Yes, you are right :slight_smile: I hadn’t looked for socket calls. We I do, I see:

19288 08:29:15 socket(PF_FILE, SOCK_STREAM, 0 <unfinished …>
19290 08:29:15 open("/usr/lib64/ooo3/program/…/basis-link/ure-link/lib/libuno_sal.so.3", O_RDONLY <unfinished …>
19288 08:29:15 <… socket resumed> ) = 5

earlier in the sequence.

I’m not sure how this helps me though as I am not familiar with sockets. I can only assume that this is related to the NLM lock thing.

By using “-o nolock” on the mount command, I don’t see any more the long delays in opening the .odp files.

Kind regards

Nigel

Well if your NAS doesn’t support locks, then that would be the solution.

nigelha wrote:
> Hi Ken
>
> Yes, you are right :slight_smile: I hadn’t looked for socket calls. We I do, I
> see:
>
> 19288 08:29:15 socket(PF_FILE, SOCK_STREAM, 0 <unfinished …>
> 19290 08:29:15
> open("/usr/lib64/ooo3/program/…/basis-link/ure-link/lib/libuno_sal.so.3",
> O_RDONLY <unfinished …>
> 19288 08:29:15 <… socket resumed> ) = 5
>
> earlier in the sequence.
>
> I’m not sure how this helps me though as I am not familiar with
> sockets. I can only assume that this is related to the NLM lock thing.
>
> By using “-o nolock” on the mount command, I don’t see any more the
> long delays in opening the .odp files.

A lot of NAS’s are all-in-ones in that they attempt to do both NFS
and SMB (and possibly other things). Sharing locks between NFS and
SMB/CIFS is possible, but “hard”, so a lot of times the “solution” is
to disable locks. If it’s pure NFS, then the locking daemon is not
working correctly on the NAS… (maybe?)…

Sometimes with a cheap NAS you get what you (don’t) pay for.