Andreas, thank you very much for this log sought-after explanation! As far as I have read manuals and the mailing list, no one ever put these two commands side by side. One would only find the advice to "make the OST read-only" - and the how-to side I also only found the "lctl --conf_param..." version.
I think anyhow the meaning and syntax of the various set_param commands is never really explained in the manual? Regards, Thomas Andreas Dilger wrote: > On Jan 16, 2009 13:45 +0100, Heiko Schroeter wrote: >> the manual (May 2008) describes on page 4-14 how to remove an OST from >> LUSTRE. >> Its says "deactivate the OST (make it read-only). >> >> Hm, i'am a bit puzzled here. >> When i deactivate the OST on the MDS using >> 'lctl --device 18 conf_param foo-OST000d.osc.active=0' the device is >> deactivated but i cannot read any files from it any longer. Quite logical. > > Ah, it looks like you are confusing two different commands here. > By using "lctl conf_param ..." you are storing this setting in the > filesystem-wide configuration file, permanently deactivating the device > on all nodes. > > If you just want to deactivate the OST only on the MDS you can use: > > lctl set_param osc.foo-OST000d.active=0 > > This means the MDS will not allocate any new objects on this OST. It will > still be active on all of the clients, so they can read or write to this > file, or delete it. > >> On the other hand using lctl "readonly" option is specified as "dangerous". > > Yes, this isn't something you should be using - it is for regression > testing only and doesn't do what you want. > >> So what is the correct approach of replacing an OST and/or what is the >> correct syntax for lctl (or whatever command) putting a device in >> read-only mode ? >> >> When the OST is in read-only mode and i "recopy" the file over the original >> one what happens to the directory structure? > > If the OST is deactivated on only the MDS, but not the clients, then the > deleted file will be cleaned up correctly on the OST. > >> Is it necessary to recreate >> it? Or is it enough to do something like this (mentioned under 3. on the >> above lustre manual page): > > >> cp /lustrefs/dir1/foo/dat.file /tmp/. >> cp /tmp/dat.file /lustrefs/dir1/foo/. > > Using "cp" likely isn't what you want to do, because "cp" doesn't change > the inode (object) allocation (even on local filesystems). More likely > you want to do: > > cp .../dat.file .../dat.file.tmp > mv .../dat.file.tmp .../dat.file > > This will create a new file (not on the OST deactivated at the MDS), > and delete the old one when the new one is moved over top of it. > > Once you have moved all of your files off of this OST then it is safe > to remove and the "conf_param" command can be used to deactivate it > permanently. > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss -- -------------------------------------------------------------------- Thomas Roth Gesellschaft für Schwerionenforschung Planckstr. 1 - 64291 Darmstadt, Germany Department: Informationstechnologie Location: SB3 1.262 Phone: +49-6159-71 1453 Fax: +49-6159-71 2986
begin:vcard fn:Thomas Roth n:Roth;Thomas org:GSI;IT adr:;;Planckstr.1;Darmstadt;;64291;Germany email;internet:t.r...@gsi.de tel;work:+49-6159-71 2126 tel;fax:+49-6159-71 2986 tel;cell:+49-176-51376960 x-mozilla-html:TRUE url:http://www.gsi.de/informationen/wti/it/index.html version:2.1 end:vcard
_______________________________________________ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss