Messages in this thread | | | Date | Mon, 21 Nov 2005 18:26:05 +0100 | From | VALETTE Eric RD-MAPS-REN <> | Subject | Re: CIFS improvements/wider testing needed |
| |
Steve French wrote: > Eric, > Thanks for the feedback - any bugs which you report which I can > reproduce - I will treat > as a very high priority and your testing is helpful.
I know you have tried to reproduce them and failed. The question was how to go further?
>> Trying to push Linux in corporate environments in such condition is >> very difficult because, due to those bugs, you cannot: >> >> 1) save a new openoffice document twice, 2) create mail folders >> from inside thunderbird (local mailbox > shared >> with windows), > > You can avoid these by mounting with "nobrl" (no remote byte range > lock) mount option (smbfs does not send byte range locks so would not > run into this problem, but would run into others). These appear to be > byte range locking problems. The problem is that cifs has to map > advisory to mandatory locks which only works if the application is > reasonably well behaved (not even Samba has support for advisory > locks although they will come with the new Unix extensions). It may > be made worse by a bug in openoffice (some Linux apps such as > Evolution lock on the "wrong" file handle which does not fail in > posix, although is sloppy coding) but I have not confirmed the byte > range lock sequence which openoffice is trying as we did with > Evolution - I did confirm that nobrl (disabling the byte range locks > on the client) works. Note that this mount option, although not > listed as a bug fix in git per-se - was added to address the > evolution etc. locking bugs. There are quite a few of the cifs > changes that fall into that category.
Well I would be surprised the "cat >> titi" command does any of this byte range lock. If the "create and later rewrite the same file" sequence fails, with a simple cat command (cat > titi ... ^D; cat >> titi), how can it works with complicated applications?
> >> 3) avoid to do FSCK after each reboot, > Not sure that cifs would cause this unless you mean that cifs was > hung and shutdown hung.
Yes : the system hangs when shutting down as the result of the "umount -a" with the last message being as described in bug N° 3237. I have to press power button for 5 seconds.
NB : manually doing the umount does exactly the same things.
> To avoid cases where cifs requests could stay > blocked forever (especially locking requests), I added a umount_begin > routine a few weeks ago to try to free threads blocked in cifs - but > what I need from users/tests if they see a cifs umount fail is to > know where the requests are hung so I can add wakeup calls for that > condition in cifs's umount_begin (you can do "echo t > > /proc/sysrq-trigger" then "dmesg > debugdata" to get the debugdata > which has the callstacks of processes blocked in kernel).
Will do that in the bug data.
>> <https://bugzilla.samba.org/show_bug.cgi?id=3237>
> Although I would like to find a workaround so it does not hang the > umount or fail umount I am not convinced that this is a typical > regression - if a server sends an illegal response which we were not > catching before ... it would be dangerous to call preventing that > potential security problem a regression.
Hanging a system systematically leading to FSCK on each reboot is not particularly helpfull given the fact that it happens whebn you are doing a shutdown in most cases.
-- eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |