Lustre discuss - May 2006 - Safety of mounting Lustre on OSS via Samba

On Jun 22, 2005  15:17 -0700, Jeffrey W. Baker wrote:
> On Wed, 2005-06-22 at 15:42 -0600, Andreas Dilger wrote:
> > On Jun 22, 2005  10:49 -0700, Jeffrey W. Baker wrote:
> > > Is there any reason to doubt the safety of mounting the Lustre
> > > filesystem on an OSS node, by way of a Samba export from a Lustre
> > > client?
> > 
> > I don''t know if "safety" is exactly the right term.
For local
> > client-on-OST type mounts it is possible with current lustre releases
> > that it deadlock during heavy IO with a memory shortage.  The OST
client
> > will be trying to write to the filesystem, and the OST cannot allocate
> > anything to complete the request, blocking on the local client
writeout.
> 
> Ah, I thought there was something more subtle.  Is it not true that the
> writeout-to-network deadlock affects all network filesystems, not just
> Lustre?  And, if I read your message correctly, the indirection through
> Samba doesn''t really help?
I''d guess it will help, because now you have to have 2 machines OOM at
the same time before they deadlock.  We haven''t tested something like
that before, so I can''t make any real comments.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

--uXxzq0nDebZQVNAZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Jun 22, 2005  10:49 -0700, Jeffrey W. Baker wrote:
> Is there any reason to doubt the safety of mounting the Lustre
> filesystem on an OSS node, by way of a Samba export from a Lustre
> client?
I don''t know if "safety" is exactly the right term.  For
local
client-on-OST type mounts it is possible with current lustre releases
that it deadlock during heavy IO with a memory shortage.  The OST client
will be trying to write to the filesystem, and the OST cannot allocate
anything to complete the request, blocking on the local client writeout.

With a remote client this might not happen because the Samba client will
normally be able to cache the write, but I suspect it is still possible
(though more difficult) to get into a similar situation.  For most
workloads it probably is a non issue.

We are of course working to fix the client-on-OST case anyways by
having the OST preallocate the buffers it needs to complete a request.
This will likely be in the next 1.4 release.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.


--uXxzq0nDebZQVNAZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCudtapIg59Q01vtYRAgMDAKCiTnGQY3D4q4vlKC1dFoDA8PBZdACbBwso
d4n/H5K88HMxQ38hOXOPSOU=yjRG
-----END PGP SIGNATURE-----

--uXxzq0nDebZQVNAZ--

On Wed, 2005-06-22 at 15:42 -0600, Andreas Dilger wrote:
> On Jun 22, 2005  10:49 -0700, Jeffrey W. Baker wrote:
> > Is there any reason to doubt the safety of mounting the Lustre
> > filesystem on an OSS node, by way of a Samba export from a Lustre
> > client?
> 
> I don''t know if "safety" is exactly the right term.  For
local
> client-on-OST type mounts it is possible with current lustre releases
> that it deadlock during heavy IO with a memory shortage.  The OST client
> will be trying to write to the filesystem, and the OST cannot allocate
> anything to complete the request, blocking on the local client writeout.
Ah, I thought there was something more subtle.  Is it not true that the
writeout-to-network deadlock affects all network filesystems, not just
Lustre?  And, if I read your message correctly, the indirection through
Samba doesn''t really help?

Thanks,
jwb

Is there any reason to doubt the safety of mounting the Lustre
filesystem on an OSS node, by way of a Samba export from a Lustre
client?

-jwb