Brian J. Murrell wrote: > On Tue, 2008-02-05 at 10:50 -0500, Craig Prescott wrote: >> However, 'lfs df' on the clients does not show >> that the OST is deactivated there, unless we *also* >> run the lctl deactivate there. Then the OST shows >> up as 'inactive' on the client, and we get the same >> message as above in the client's syslog. > > Do you really want the OST deactivated on the clients? I think your > goal is to effectively remove the OST from further space allocation > decisions, yes? You still want the data on the OST available to clients > to read or overwrite, correct? Deactivating on the clients will make > the OST completely unavailable to the clients, even for read operations.
Thanks for your answer - that was what I wanted to know. Yes, we only want the OST removed from further space allocation decisions. >> So I have a question - if I want to deactivate an OST >> (preventing new files from being written to it) while >> I sort out what files to shuffle off of a full OST, >> where should I run 'lctl deactivate'? > > On the MDT. Deactivation on the MDT prevents the MDT from further > allocating objects on it, but does not prevent clients from reading or > writing to existing objects. Got it. Thanks again. Cheers, Craig _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
