On 08/09/2020 18:37, IBM Spectrum Scale wrote:
I think it is incorrect to assume that a command that continues
after detecting the working directory has been removed is going to
cause damage to the file system.
No I am not assuming it will cause damage. I am making the fairly
reasonable assumption that any command which fails has an increased
probability of causing damage to the file system over one that completes
successfully.
Further, there is no a priori means to confirm if the lack of a
working directory will cause the command to fail.
Which is why baling out is a more sensible default that ploughing on
regardless.
I will agree that there may be admins that would prefer the command
fail fast and allow them to restart the command anew, but I suspect
there are admins that prefer the command press ahead in hopes that
it can complete successfully and not require another execution.
I am sure that there are inexperienced admins who have yet to be battle
scared that would want such reckless default behaviour. Pandering to
their naivety is not a sensible approach IMHO.
The downside if a large file system (and production GPFS file systems
tend to be large) going "puff" is so massive that the precaution
principle should apply.
One wonders if we are seeing the difference between a US and European
mindset here.
I'm sure we can conjure scenarios that support both points of view.
Perhaps what is desired is a message that more clearly describes what
is being undertaken. For example, "The current working directory,
<directory_name>, no longer exists. Execution continues."
That is what --force is for. If you are sufficiently reckless that you
want something to continue in the event of a possible error you have the
option to stick that on every command you run. Meanwhile the sane admins
get a system that defaults to proceeding in the safer manner possible.
JAB.
--
Jonathan A. Buzzard Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
