Hi; One of our OSTs filled up. Once we realized this, we executed lctl --device 9 deactivate on our fs''s combo MDS/MGS machine. We saw in the syslog that the OST in question was deactivated: Lustre: setting import ufhpc-OST0008_UUID INACTIVE by administrator request 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. 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''? Everywhere? Thanks, Craig --- Craig Prescott UF HPC Center
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.> 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. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080205/2c6dcec6/attachment-0002.bin
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