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

[Alex Crow]

On 14/07/16 14:29, Volker Lendecke wrote:
> On Thu, Jul 14, 2016 at 02:22:12PM +0100, Alex Crow wrote:
>> At the moment we're pretty happy with the Samba side of things. I
>> did wonder if there was any help that you kind chaps might be able
>> to give to the MooseFS guys if they need it (they've not asked yet
>> but I've suggested they might be able to). Overall it's working
> The main hint I would like to give to the MooseFS developers is to get
> ping_pong -rw working. If you need any assistance in setting that up
> and getting arguments on why this is important, let us know!
>
> With best regards,
>
> Volker

Hi Volker,

Any arguments that I can pass on would be much appreciated.

I've also had a try with RozoFS, which did not work as expected as it 
only supports block-level locks (4096 bytes) so the first lock prevent 
further locks in that block range, which naturally causes ping_pong to 
stall. However I am told by their devs that this should not be an issue 
for CTDB's recovery lock or Samba as they should not need to lock ranges 
of less than a 4k, and they in fact integrate CTDB for their customers.

Best regards

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).