[lustre-discuss] Stop writes for users

[Patrick Farrell]

Connections on demand has been done and is not relevant here – It just idles unused connections to save resources, no impact on ability to write, etc.


  *   Patrick

From: lustre-discuss <lustre-discuss-bounces at lists.lustre.org> on behalf of Alexander I Kulyavtsev <aik at fnal.gov>
Date: Tuesday, May 14, 2019 at 11:42 AM
To: "lustre-discuss at lists.lustre.org" <lustre-discuss at lists.lustre.org>
Subject: Re: [lustre-discuss] Stop writes for users


There was feature request, and there were corresponding LU:

LU-5703 - Lustre quiesce

LU-7236 - connections on demand



Alex.

________________________________
From: lustre-discuss <lustre-discuss-bounces at lists.lustre.org> on behalf of Robert Redl <robert.redl at lmu.de>
Sent: Tuesday, May 14, 2019 10:36 AM
To: lustre-discuss at lists.lustre.org
Subject: Re: [lustre-discuss] Stop writes for users


I don't know is this really works for this use case, but newer Lustre versions have the possibility to create a write barrier, which is normally part of the snapshot process.

Have a look at lctl barrier_freeze.
On 5/14/19 5:25 PM, Mohr Jr, Richard Frank (Rick Mohr) wrote:


On May 13, 2019, at 6:51 PM, Fernando Pérez <fperez at icm.csic.es><mailto:fperez at icm.csic.es> wrote:



Is there a way to stop file writes for all users or for groups without using quotes?



We have a lustre filesystem with corrupted quotes and I need to stop the write for all users (or for some users).

There are ways to deactivate OSTs, but those are intended to stop creation of new file objects on those OSTs and don’t actually stop writes to existing files.  I don’t think that mounting OSTs read-only  (with “mount -t lustre -o ro …”) works because Lustre updates some info when it mounts the target (but this might be based on old info so I could be wrong).  You could remount all the clients read-only, but I don’t know if this is practical for you.



The only other option I can think of would be if there was a client-side parameter that could be set via “lctl conf_param” that might cause the clients to treat all the targets as read-only.  But if there is such a parameter, I am not familiar with it.



--

Rick Mohr

Senior HPC System Administrator

National Institute for Computational Sciences

http://www.nics.tennessee.edu



_______________________________________________

lustre-discuss mailing list

lustre-discuss at lists.lustre.org<mailto:lustre-discuss at lists.lustre.org>

http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
--

Dr. Robert Redl
Scientific Programmer, "Waves to Weather" (SFB/TRR165)
Meteorologisches Institut
Ludwig-Maximilians-Universität München
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20190514/b4a6064b/attachment.html>