Lustre discuss - Jul 2010 - Confusion regarding deactivating OSTs

Hi.

We are attempting to recover from a RAID controller issue in a storage  
array that holds a couple of OSTs. We would like to tread carefully  
and eventually remount the OSTs read-only so that clients can read  
files striped to these OSTs but not write data. According to the 1.8  
manual, running ''lctl deactivate'' on just the MDS will prevent
new
objects from being allocated to the OST but will allow reads AND  
writes to existing objects. Is there any way of preventing all kinds  
of write activity to the OST (not just new object creation)?

-------
Yemi

On Fri, 2010-07-09 at 11:00 -0700, Adeyemi Adesanya wrote:
> 
> Hi.
Hi,
> Is there any way of preventing all kinds  
> of write activity to the OST (not just new object creation)?
No, since that would prevent updating a file since we do not have any
COW (copy-on-write) semantics.  Out of interest''s sake, given that we
lack COW semantics, are you proposing that your users get "read only"
errors on (sections of) files where those objects lie on such an OST?
Or were you assuming COW semantics?

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url :
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20100709/720d022a/attachment.bin

It is possible for the clients to mount the whole Filesystem read-only, which
sets a flag on the MDS and OST for that client to have it return -EROFS for any
Filesystem modifying operations.

However, it isn''t possible to mount the OST itself read-only today. At
one time there were patches in bugzilla that started to investigate this but
they were never finished and landed.

I suspect it wouldn''t be too much worknfor someone to try mounting the
OST with the "-o ro" mount option and then fixing the few places at
mount time that are depending on being able to write to the filesystem. At the
same time, I suspect that this isn''t what you want to be doing when
your system is already down, so it will have to be at a later time perhaps.

Cheers, Andreas

On 2010-07-09, at 12:00, Adeyemi Adesanya <yemi at slac.stanford.edu>
wrote:
> 
> 
> Hi.
> 
> We are attempting to recover from a RAID controller issue in a storage  
> array that holds a couple of OSTs. We would like to tread carefully  
> and eventually remount the OSTs read-only so that clients can read  
> files striped to these OSTs but not write data. According to the 1.8  
> manual, running ''lctl deactivate'' on just the MDS will
prevent new
> objects from being allocated to the OST but will allow reads AND  
> writes to existing objects. Is there any way of preventing all kinds  
> of write activity to the OST (not just new object creation)?
> 
> -------
> Yemi
> _______________________________________________
> Lustre-discuss mailing list
> Lustre-discuss at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-discuss