[Samba] Winbind process stuck at 100% after changing use_mmap to no

[Alex Crow]

On 05/07/16 21:21, Volker Lendecke wrote:
> On Tue, Jul 05, 2016 at 09:06:54PM +0100, Alex Crow wrote:
>>> Why are you still using "use mmap = no" then?
>> Because the wiki article does not explicitly state that mmap
>> coherence is only needed for areas that store tdb files. I'd perhaps
> Maybe that is the omission in the docs. I thought I had mentioned that
> "use mmap" is only relevant for tdb files, not for plain exported
> shares.

Perhaps I did not read one of your replies carefully enough, so I
apologise if that is the case.
>
>> incorrectly deduced that as you had explicitly said that "private
>> dir" on the cluster FS was a bad idea, that disabling that would
>> stop all tdb files being written to the MooseFS FS, and that would
>> be the solution.
> The solution is to use ctdb with the database files on local
> directories. That's what ctdb is for.

Yes, I'm clear on that now - I'm just surprised that the "private dir"
stuff is all over the internet, not just on the Samba wiki. Sometimes
this global sharing community does go a bit wrong!

>
>> My understanding was the "use mmap" affected general FS operations
>> from clients, not just tdb files.
> It just affects tdb files.

Thanks for the confirmation, I was already suspecting this was the case.

>
>>> This piece is wrong. The wiki should give you hints who wrote this.
>>> Please contact the author of those lines, refer to the mail thread
>>> here and ask these lines to be changed or even better -- change these
>>> lines yourself.
>> I see what you mean here, but I'd not want to edit a wiki when I
>> have less idea of the facts that the person that wrote the original
>> text! I'd not want to update it without knowing the precise facts,
>> hence my reaching out to the Samba list and yourself.
> Well, now you should have a better understanding of the issue :-)

I do indeed and shall edit the page as much as I feel confident to do so.

>
>>> If MooseFS does not even survive -rw without asking for mmap coherence,
>>> just don't use it for Samba. This will eat your data for breakfast.
>>> Gluster was there loooong ago, and they fixed it before becoming a
>>> viable storage solution for Samba.
>>>
>>> Volker
>> MooseFS does not ask for mmap coherence. It has inconsistent results
>> on a plain -rw test.
> MooseFS needs to fix that. ping_pong with -rw is pretty basic Posix
> stuff. Admittedly it seems to be very hard for cluster file systems to
> implement, but it is essential if you want to provide Posix semantics.
> Samba and SMB clients depend on this. SMB clients coordinate via byte
> range locks, and data coherence coordinated by those locks just basically
> assumed.

As I said on another email that has crossed this, I have the devs
probing the problem right now. As it uses an central in-memory metadata
server for all locking, I'm hoping it will be an easy fix for them.

>
> ping_pong was explicitly designed by Andrew Tridgell as a torture test
> case for cluster file systems developers. It does not come with the
> huge SMB baggage that is difficult to set up for cluster file systems
> developers. The calls it makes are simple enough to be understandable
> in file system traces.

Yes, I looked at the code and it is indeed terse but brutal!

Many thanks

Alex


--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
This email is not intended to, nor should it be taken to, constitute advice.
The information provided is correct to our knowledge & belief and must not
be used as a substitute for obtaining tax, regulatory, investment, legal or
any other appropriate advice.

"Transact" is operated by Integrated Financial Arrangements Ltd.
29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300.
(Registered office: as above; Registered in England and Wales under
number: 3727592). Authorised and regulated by the Financial Conduct
Authority (entered on the Financial Services Register; no. 190856).