Samba storage is not online

[yarii]

Ok - thanks.

 

[yarii]

After upgrading to newest version I checked again.

So I did:
- remove all the CIFS storage
- add again storage
- check if it's mounted correctly ( ls /mnt/pve/backup)
- check if it's enable in GUI state DATACENTER->Storage (all mounted CIFS are ENABLED)
- click the GUI DATACENTER-->VPS_TEST--> Click the storage named backup--> Click CONTENTS and then see:
error "storage 'backup' is not online (500)"

But I did not get this not for every share and not every time.

After clicking GUI-->Storage-->Summary I never get no error.

But I see very strange behavior when I get an error - in log there are errors for all shares.

 

[wolfgang]

Can you send the logs?

 

[yarii]

What kind of logs do You want? Yes I can do debug because the machine is used only a little.

Maybe the check_connection function is good for first time after mount or only after clicking "Summary" and there should be new function for example like check_mount_cifs whitch would not use smbclient but should do check in local mount place (it would be much more faster because making new connection, login again and all the things whitch are done there like negotiating protocole version and authentication type is not required). It's also much more clean for logs on destination CIFS server.

What do you think about my idea?

 

[wolfgang]

And How should this work the check on local mount?

 

[yarii]

For mount with RW privileges maybe we could use ioping? ...and then we get also useful latency information!

 

[wolfgang]

Generall a good idea.

I have checked the source code of ioping.
The write/read data from the storage.
Only write would a good test to prove that the storage is online.

If we use write we have two problems.
1.) All 5sec a 4KB will be written on the storage.
2.) If the storage is not online ioping will in a blocking state because it will wait for IO.
We have a hard timeout of 2sec. And this task can't be canceled because ioping is uninterruptable because it waits for IO.

 

[yarii]

What about storages that are mounted only RO? So this is the third problem.

 

[yarii]

Maybe instead of ioping we could do stat mountedplace?

 

[wolfgang]

mountedplace?

I don't know this have you got a link?

 

[yarii]

I mean command stat...for example:

stat /mnt/pve/backup-input

 

[wolfgang]

stat could work but I have to make some further tests.

 

[yarii]

It would be nice to use working CIFS plugin. Please write here if You do tests.

 

[yarii]

@wolfgang Did You do the test with stat command?

 

[wolfgang]

Yes, it is blocking in some cases if the storage is offline, so we can't use it.

 

[yarii]

@wolfgang maybe we could use stat with timeout command at the front?

$ timeout -k 2 stat file

Could You test your problematic scenario with this check?

 

[wolfgang]

Stat is a syscall and you can't interrupt kernel processes what are waiting for IO.
That is the root of the problem.
May the user space return but then you have a zombie kernel process.

 

[yarii]

Is there any hope that this case willbe resolved and we could use CIFS plugin?

So maybe we could use timeout -k1 with ls or cat?

 

[wolfgang]

It is working here and I know also Synology user out there where it works perfectly.
I know that the extra connection are not nice but there is no proper function alternative test for this method.

 

[yarii]

We have mounted share in /mnt/pve/storagename so we should use connection that we have and not create new one.

It's working good ONLY when the synology is idle but not working propely when synology has got some load. I can reproduce this behavior. When we use etc/fstab and mount there is no problem.

What about doing timeout -k2 'echo "1234" > hostname.lockfile.pid' ?