[lustre-discuss] Making a file system read-only

[E.S. Rosenberg]

Hi Cameron,

On Mon, Feb 5, 2018 at 10:54 PM, Cameron Harr <harr1 at llnl.gov> wrote:

> Greetings,
>
> I'll be retiring a 2.5 ZFS-backed file system in the coming months and
> plan on putting it in a "read-only" state for 6 weeks or so to let users
> archive or migrate data they want. The optimal, if slightly contradictory,
> definition of "read-only" for me would be to allow unlinks, but disallow
> all other writes; however, if that's not possible, then disallowing all
> writes would be sufficient. I will be doing some testing, but our 2.5 T&D
> system won't be available for several days and am therefore soliciting
> advice up front.
>
> Option 1 is to remount the file system on the clients in read-only mode,
> but I can imagine a couple problems with this method.
>
Just out of curiosity what type of problems do you fore-see? Missing a
client still being rw?

>
> Option 2 is to deactivate the OSTs with lctl, but that also leaves me with
> some questions. In section 14.8.3.1a of the Lustre manual, it recommends
> setting max_create_count=0 with Lustre 2.9 and above. I'm using 2.5, not
> 2.9, but noticed that /proc/fs/lustre/osp/fs-*-osc-MDT0000/max_create_count
> does indeed exist. Does setting that option in 2.5 still have an effect in
> prohibiting new file and directory creates? Additionally, will clients be
> OK having all OSTs inactive?
>
There was some discussion of making a/multiple OSTs read-only for data
migration last year that you may find useful:
http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/2017-March/014294.html
HTH,
Eli

>
> Is there another viable option?
>
> Many thanks,
> Cameron
>
>
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20180206/2c4eb6c6/attachment.html>