Pulling power

How well does unRAID handle it's power being yanked on a fairly regular basis?  Does the RAID write-hole exist?

 

I ask due to a corner use-case we have, which I hope unRAID can fill, but the probability of frequent unclean shutdowns is high and unavoidable.

Uninterruptible Power Supply

On the assumption that you realize your asking a question akin to "what happens if I shoot this guy in the heart?", I think the answer is - not very well, better than some and worse than others.  Keeping in mind that I don't work for Lime Technology so this is observational guesswork:

 

An idle Windows box might come right back up again.

 

An active FreeNAS server would probably suffer loss of data and some nasty file system corruption.

 

An active unRAID server could suffer loss of in-flight writes and potentially file system corruption.  unRAID does in-memory caching of writes but quickly flushes its buffers.  So, it depends on exactly what was happening at the moment of power loss.  The exposure should be less than a FreeNAS where file system structures are resident in memory, though.  It would, however, definitely detect the unclean shutdown and do a parity check on restart which would be very undesirable for an operational server.

 

So like Trurl said - buy a UPS  .

A UPS doesn't work for our application; it would be a mobile server which would be regularly packed up in a truck and shipped to other locations.  (It would actually be on a UPS during use, but the UPS itself would be shut off during transit.)

 

All the writes should be complete when the power is yanked; it's a small number of very large files, not a DB or random-access application.  If unRAID flushes its write-cache quickly it shouldn't be an issue, but if it lingers onto the write cache that could become a problem.

 

When I'm the one operating it, I will do a proper shutdown procedure, but I can see other people just turning it off, which is why I asked this question.

A UPS doesn't work for our application; it would be a mobile server which would be regularly packed up in a truck and shipped to other locations.  (It would actually be on a UPS during use, but the UPS itself would be shut off during transit.)

 

All the writes should be complete when the power is yanked; it's a small number of very large files, not a DB or random-access application.  If unRAID flushes its write-cache quickly it shouldn't be an issue, but if it lingers onto the write cache that could become a problem.

 

When I'm the one operating it, I will do a proper shutdown procedure, but I can see other people just turning it off, which is why I asked this question.

 

Basically it is a matter of time before you will run into trouble... That simply is not the case you go about with any kind of storage...

 

That said... An advantage of unraid is that each disk has its own filesystem, so where another type of array might totally get in trouble when you yank the power you would possibly run less of a risk with unraid.. The issue would be limited to the one disk the write was done on..

 

You could also think about using a cache drive and setting ALL your shares to run through the cache disk.. That would mean that an error in writing could only hurt the cache drive and not all the other drives..

 

Also: You will get hit with a parity check on every yanked power event so you will at least see it got yanked so you can talk the person responsible..

 

Ergo... Something you should just never do.. And it will go wrong.. Possibly a bit later with unraid compared to others..

The powerdown plugin used to do a controlled shutdown when you hit the server power button.  The functionality of that plugin has largely been integrated into unRAID, but you should check to see about that feature.

 

Are your data handling/backup/redundancy procedures such that you can you run without parity?

@Helmonder:

We are going to run everything through cache, although I just noticed that the cache is only setup to dump once every night in a cron job; that won't work for us as we will be dumping several TB simultaneously and not leaving the server on overnight most likely, so I'm going to need to look into changing that.  (Basically go to a site, backup quite a few very large files, leave site for another site.)

 

@tdallen:

No, we need parity.  In fact, we will probably do dual-parity.  With the size of the array I'm looking at doing, I would probably do triple-parity if possible.

How well does unRAID handle it's power being yanked on a fairly regular basis?  Does the RAID write-hole exist?

 

I ask due to a corner use-case we have, which I hope unRAID can fill, but the probability of frequent unclean shutdowns is high and unavoidable.

In my (and many others) experience, BTRFS is extremely intolerant of unclean shutdowns. If you want the best resilience to unclean shutdowns, XFS is currently the best option IMHO.

@Helmonder:

We are going to run everything through cache, although I just noticed that the cache is only setup to dump once every night in a cron job; that won't work for us as we will be dumping several TB simultaneously and not leaving the server on overnight most likely, so I'm going to need to look into changing that.  (Basically go to a site, backup quite a few very large files, leave site for another site.)

 

@tdallen:

No, we need parity.  In fact, we will probably do dual-parity.  With the size of the array I'm looking at doing, I would probably do triple-parity if possible.

 

The cache drive can run every hour if you want.. Ofcourse that will mean that it still might happen that power is pulled while the cache-mover operation is running so you loose the benefit.

How well does unRAID handle it's power being yanked on a fairly regular basis?  Does the RAID write-hole exist?

 

I ask due to a corner use-case we have, which I hope unRAID can fill, but the probability of frequent unclean shutdowns is high and unavoidable.

In my (and many others) experience, BTRFS is extremely intolerant of unclean shutdowns. If you want the best resilience to unclean shutdowns, XFS is currently the best option IMHO.

 

The whole thing is russian roulette though... We can debate on how big the bullet reservoir is (eg: how long does it take for data loss), but as some point you will absolutely shoot yourself (experience dataloss). Btw: the parity protection will most likely -not-help in these cases (a not completed write will quite possibly mean that the parity operation also has not been completed).

 

Make sure you run regular and complete backups.

 

Or even better:

 

If \users pulls plug\ then \cut of hands\