Hi all, sorry if this has been answered before, but I could find only one un-answered question concerning this topic in the archive. Question is for lustre 1.8.1. If I like to deactivate write operation for an OST temporary, but allow clients to read still data from the OST, disabling the OST on the MDS will do the job as described in the admin guide. In case an OST was lost and clients shouldn''t contact the OST anymore (if OST is damaged irreversible) even for read operation, could I execute the ''lcl --device <id> deactivate'' command also on the clients? Or is this action superfluous since the client will receive EIO''s anyway? Many thanks in advance. -Frank Heckes ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir''in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
On Thu, 2009-09-24 at 11:31 +0200, Frank Heckes wrote:> Hi all,Hi,> sorry if this has been answered before, but I could find only one > un-answered question concerning this topic in the archive.Hrm. Strange, as I believe this has been answered in the archive many, many times. I believe the answer to this is in the manual too.> If I like to deactivate write operation for an OST temporary, but allow > clients to read still data from the OST, disabling the OST on the MDS > will do the job as described in the admin guide.Not quite. Disabling on the MDS only disables "new allocation", not write. That means that new objects won''t be allocated to files from the deactivated OST. Writes to existing objects will still be allowed.> In case an OST was lost and clients shouldn''t contact the OST anymore > (if OST is damaged irreversible) even for read operation, could I > execute the ''lcl --device <id> deactivate'' command also on the clients?Hrm. I usually fiddle with the proc file directly on this, but suffice it to say that whatever operation you are using on the MDS to deactivate an OST can be used on the client to return EIOs when a given OST is accessed.> Or is this action superfluous since the client will receive EIO''s > anyway?No. The client will only receive EIOs if that client has deactivated the OST.> Many thanks in advance.NP. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090924/4b1d4dfb/attachment.bin
On Donnerstag 24 September 2009 12:58:35 Brian J. Murrell wrote: Get device list on MDS: lctl dl Disabling write only. Read on clients possible.: lctl set_param osc.lustre-OST000d-osc.active=0 Disable read/write (disabling device permanently): lctl --device 18 conf_param lustre-OST000d.osc.active=0 (18 and OST000d) has to be replaced by your stuff of course) Watchout: A bug in ''lfs'' (still not fixed) will not step over an deactivated device. We do use a patched version here to get around. Version 1.6 and 1.8. https://bugzilla.lustre.org/show_bug.cgi?id=18329 All commands on MDS. Thanks to Andreas Dilger some time ago who pointed that out. Regards Heiko> On Thu, 2009-09-24 at 11:31 +0200, Frank Heckes wrote: > > Hi all, > > Hi, > > > sorry if this has been answered before, but I could find only one > > un-answered question concerning this topic in the archive. > > Hrm. Strange, as I believe this has been answered in the archive many, > many times. I believe the answer to this is in the manual too. > > > If I like to deactivate write operation for an OST temporary, but allow > > clients to read still data from the OST, disabling the OST on the MDS > > will do the job as described in the admin guide. > > Not quite. Disabling on the MDS only disables "new allocation", not > write. That means that new objects won''t be allocated to files from the > deactivated OST. Writes to existing objects will still be allowed. > > > In case an OST was lost and clients shouldn''t contact the OST anymore > > (if OST is damaged irreversible) even for read operation, could I > > execute the ''lcl --device <id> deactivate'' command also on the clients? > > Hrm. I usually fiddle with the proc file directly on this, but suffice > it to say that whatever operation you are using on the MDS to deactivate > an OST can be used on the client to return EIOs when a given OST is > accessed. > > > Or is this action superfluous since the client will receive EIO''s > > anyway? > > No. The client will only receive EIOs if that client has deactivated > the OST. > > > Many thanks in advance. > > NP. > > b. > >-- ----------------------------------------------------------------------- !!! NEUE TELEPHONNUMMER !!! !!! NEW PHONE NUMBER !!! Dipl.-Ing. Heiko Schr?ter Institute of Environmental Physics (IUP) phone: ++49-(0)421-218-62092 Institute of Remote Sensing (IFE) fax: ++49-(0)421-218-4555 University of Bremen (FB1) P.O. Box 330440 email: schroete at iup.physik.uni-bremen.de Otto-Hahn-Allee 1 28359 Bremen Germany ----------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090924/10a0ad3a/attachment.html
On Thu, 2009-09-24 at 13:18 +0200, Heiko Schr?ter wrote:> > Disabling write only. Read on clients possible.: > lctl set_param osc.lustre-OST000d-osc.active=0No. This does not disable *write*. It just disables "new object allocation". This is an important distinction because it does NOT prevent writing to existing files on the OST, which will re-use an existing object. This is important when trying to consider the status of an OST after it has been disabled on the OST. It''s content could still change in form of updated object contents.> Disable read/write (disabling device permanently): > lctl --device 18 conf_param lustre-OST000d.osc.active=0 > (18 and OST000d) has to be replaced by your stuff of course)It should be noted that disabling I/O to/from an OST can be done temporarily by making changes to "active" on the clients with lctl set_param. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090924/77fab927/attachment.bin
On Sep 24, 2009 13:18 +0200, Heiko Schr?ter wrote:> Watchout: > A bug in ''lfs'' (still not fixed) will not step over an deactivated device. > We do use a patched version here to get around. Version 1.6 and 1.8. > https://bugzilla.lustre.org/show_bug.cgi?id=18329I was just checking to see why the patch in this bug was not landed, but in fact there is no patch in that bug. Could you please attach your patch so that it can be landed. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
On Freitag 25 September 2009 12:31:58 you wrote:> Just attaching the patch on the bug is sufficient, and marking > "inspection ? adilger at sun.com". It is fine even if you don''t think > this is a proper fix (though please add some words to that effect), > because it will at least provide a starting point for a better fix > if one is needed.Done. Just to get back to the subject, what _is_ the proper sequence to deactivate an OST ? We have used our scenario (lctl set_param resp. conf_param) for deactivating/copying up to now 3 x 6,5TB lustre Partitions (OSTs) and it worked ok. Are we just hard hearted enough to ignore the underlying lustre mechanisms ? Thanks and Regards Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090925/502cb6ff/attachment.html
On Sep 25, 2009 12:56 +0200, Heiko Schr?ter wrote:> On Freitag 25 September 2009 12:31:58 you wrote: > > Just attaching the patch on the bug is sufficient, and marking > > "inspection ? adilger at sun.com". It is fine even if you don''t think > > this is a proper fix (though please add some words to that effect), > > because it will at least provide a starting point for a better fix > > if one is needed. > > Just to get back to the subject, what _is_ the proper sequence to > deactivate an OST ?What you posted is fine.> We have used our scenario (lctl set_param resp. conf_param) for deactivating/copying up to now 3 x 6,5TB lustre Partitions (OSTs) and it worked ok. > Are we just hard hearted enough to ignore the underlying lustre mechanisms ? > > Thanks and Regards > HeikoCheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.