Parity on system folders?

[Pinch]

Hello all!

 

Just a quick question: I currently have a /.custom dir on my cache, but the thing is, that the files in that dir are probably the ones most important for me to be protected by parity; since the Mover ignores system folders, I was wondering if they're even protected by parity if placed on a disk in the array?

[dgaschk]

Yes, they are protected.

[christuf]

Not wishing to contradict you @dgaschk - perhaps I've misread the question...

 

Are you asking if the /mnt/cache/.custom directory is protected by parity?  If so, I'm certain the answer is no.  In order to protect myself, I have a cron job scheduled daily to copy the content of the .custom directory to a disk in the protected array.  If you're doing doing that, then that copy is protected (although the original isn't)

 

Only files that are moved off of the cache drive by the mover script become protected... anything that remains on the cache drive (like your .custom directory) isn't.

 

[dgaschk]

The cache drive is not in the array. Anything on a disk in the array is protected.

[Joe L.]

nothing on the cache drive, regardless of the name of the folder, is protected.

 

top level folders on the cache drive with names starting with "." are not moved to the protected array, but other than that, they have no special meaning... they are not "system" folders... they are just ignored by the mover script.

 

I'll repeat... nothing on the cache drive is protected from a drive failure.

[lionelhutz]

I was wondering if they're even protected by parity if placed on a disk in the array?

 

Everything placed on a disk in the array is protected. The cache disk is not a protected array disk.

 

Peter

[Pinch]

Sorry for not being clear. I know nothing on the cache disk is protected by parity, so I was just making sure that if the .custom directory is moved to an array disk it would be protected - which seems to be the case. Thanks for the replies

In order to protect myself, I have a cron job scheduled daily to copy the content of the .custom directory to a disk in the protected array.  If you're doing doing that, then that copy is protected (although the original isn't)

Just out of curiosity, what's the advantage in doing it this way? Why not just use the dir in the protected array?

[christuf]

Just out of curiosity, what's the advantage in doing it this way? Why not just use the dir in the protected array?

 

Allows the apps to run on the cache drive which is always spun-up, and the data drives to remains spun-down.  Make sense?

[Joe L.]

Just out of curiosity, what's the advantage in doing it this way? Why not just use the dir in the protected array?

 

Allows the apps to run on the cache drive which is always spun-up, and the data drives to remains spun-down.  Make sense?

and, when writing to the cache drive the parity drive does not need to spin up, therefore, saving a bit of power.

[christuf]

Just out of curiosity, what's the advantage in doing it this way? Why not just use the dir in the protected array?

 

Allows the apps to run on the cache drive which is always spun-up, and the data drives to remains spun-down.  Make sense?

and, when writing to the cache drive the parity drive does not need to spin up, therefore, saving a bit of power.

Hadn't thought of that... nice bonus

[Pinch]

Allows the apps to run on the cache drive which is always spun-up, and the data drives to remains spun-down.  Make sense?

Sure - in my case, the content of .custom is what's keeping the cache drive spun-up, so it wouldn't make much of a difference, though. I hadn't thought of what Joe said; since some of the apps in my .custom are constantly writing logs, this would effectively mean that my parity drive would always be spun-up too. That's a good reason to let .custom stay on the cache!