<div dir="ltr">Thanks for the explanation. There was a problem with the iscsi target. It is already multi-path. Anyhow, I was expecting things to come back online after the problem was resolved. This kind of created a data loss situation and I thought Lustre was resilient not to lose the whole OST. Here the OST became completely unmountable. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 7 Nov 2023 at 13:56, Andreas Dilger <<a href="mailto:adilger@whamcloud.com">adilger@whamcloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The OST went read-only because that is what happens when the block device disappears underneath it. That is a behavior of ext4 and other local filesystems as well. <br>
<br>
If you look in the console logs you would see SCSI errors and the filesystem being remounted read-only. <br>
<br>
To have reliability in the face of such storage issues you need to use dm-multipath. <br>
<br>
Cheers, Andreas<br>
<br>
> On Nov 5, 2023, at 09:13, Backer via lustre-discuss <<a href="mailto:lustre-discuss@lists.lustre.org" target="_blank">lustre-discuss@lists.lustre.org</a>> wrote:<br>
> <br>
> - Why did OST become in this state after the write failure and was mounted RO.  The write error was due to iSCSI target going offline and coming back after a few seconds later. <br>
</blockquote></div>