When running commands that are going to take awhile, I frequently start them with the nohup command, disown the command from the current session or queue them for later execution. The reason is that if I’m running them from a Terminal or SSH session and the session is broken I want to make sure they complete. To schedule a job for later execution, use at. For example, if I want to perform a simple command, I can schedule it in a minute by running it as an echo piped to at: echo "goldengirlsfix.sh" | at now + 2 minutes Note, if using 1 minute, you’ll need that to be singular.…
-
-
Don't Defrag the Whole SAN
I see a numer of environments that are running routine defragmentation scripts on Xsan volumes. I do not agree with this practice, but given certain edge cases I have watched it happen. When defragmenting a volume, there is no reason to do so to the entire volume. Especially if much of the content is static and not changing very often. And if specific files doesn’t have a lot of extents then they are easily skipped. Let’s look at a couple of quick ways to narrow down your defrag using snfsdefrag. The first is by specifying the path. In this case you would specify a -r option and follow that with…
-
Isolating iNodes in Xsan cvfsck Output
I’ve noticed a couple of occasions where data corruption in Xsan causes a perceived data loss on a volume. This does not always mean that you have to restore from backup. Given the cvfsck output, you can isolate the iNodes using the following: cat cvfsck.txt | grep *Error* | cut -c 27-36 > iNodeList.txt Once isolated you can then use the cvfsdb tool to correlate this to file names. For example, if you have an iNode of 0x20643c8 then you can convert this into a file name using the following: cvfsdb> show inode 0x20643c8 The output will be similar to the following: 000: 0100 8000 3f04 0327 5250 2daa 0000…
-
Xsan: Corruption
Volumes can become corrupt no matter what file system you are talking about (er, there might a magical file system out there that cannot become corrupted but I’ve never heard of it and would like to sell a certain bridge to you if you have). Xsan is no different and so you need to be ready to use the command line to combat said corruption. fsck is the traditional *nix tool to fix issues with volume corruption. cvfsck is the weird cousin that’s used for Xsan. If you see any iNode errors in your logs, corruption errors, high latency or just too many weird issues to shake a stick at…