4

I've got a raspberry pi where I want to connect an external HDD. Now I'm thinking which filesystem I will use. The problem is that the raspberry pi will be shut down from time to time without unmounting the HDD. So which filesystem is the most robust one for this usecase?

2
  • How will it be shutdown? Why can't you unmount cleanly?
    – terdon
    Sep 24, 2012 at 17:19
  • sometimes just someone turns off the power and the whole system is off
    – soupdiver
    Sep 24, 2012 at 17:45

3 Answers 3

4

Almost any read-write filesystem doesn't behave all that well when being shutdown in the middle of any operation. Using a filesystem with a journal will be better, this will at least minimize any issues. There isn't any really huge difference that I am aware of between the various options.

What you should strongly consider is using something like autofs to only mount the filesystem on demand. Autofs can be configured to unmount the filesystem when it hasn't been in use after a configurable period of time. In this way your filesystem will be unmounted and completely safe, unless you shut the system down while it is in the middle of, or right after you had trying to actually do something with the filesystem.

got a tutorial for setting up the auto unmount?

Without knowing the what version of Linux you are using I don't have a specific tutorial. Here are some links that may get you started. The key point is the --timeout which sets how long the filesystem will stay mounted when no files are in-use.

4
  • U may got a tutorial for setting up the auto unmount when idling? I can't find anything suiting right now :/
    – soupdiver
    Sep 24, 2012 at 18:16
  • 1
    The / filesystem will always be in use won't it? How can autofs help in his case?
    – terdon
    Sep 24, 2012 at 18:27
  • @terdon, you are right the / will always be in use. But since the question was about an external drive, I was assuming that the request was about some kind of storage he was setting up for data which programs will not keep open the entire time. Perhaps my assumption is bad, but without explicit constraints in the question I think my answer might be helpful.
    – Zoredache
    Sep 24, 2012 at 19:36
  • 1
    If you choose ext[34], data=ordered (or even data=journal), barrier=1 and commit=1 might save the day. Dropping DM, MD or LVM avoids problems with caching in those layers.
    – Eroen
    Sep 24, 2012 at 19:54
4

In principle this should be an excellent use case for a Log-structured file system. I have little experience with them, but NILFS looks nice and has been in the mainline Linux kernel for some time. In principle, it creates each change to the file system as a patch to be applied on top of the previous state. That way, one should be able to easily return to the previous state if there is a problem with the latest state (for example because of an untimely power failure), since nothing is generally overwritten in normal use.

On the other hand, NILFS is not as mature as ext3, nor are there nearly the same number of recovery tools if anything goes awry. Also note that when I say things are possible in the previous paragraph, that may very well mean you have to manually compile and use some software to do it.

NILFS also requires occasional clean-up as overwriting or deleting files doesn't actually free any disk space. I believe this happens automatically by default. You may want to make sure this happens at a time when power does not disappear from the device.

1

The question sounds to me very ill. No matter how strong a filesystem is, halting the system in the middle of operation is buying everyday all the lottery for massive filesystem corruption.

By using a GPIO you could signal your device that you want to switch it of. (Normal desktop PCs do have this line input long ago).

With some external circuit you could get your device powered off only after the end of the halt procedure. But you must be sure that the bad cats keep their paws the actual power line.

I have a Sheevaplug, where the LED is user-configurable and I added a script to be run just before the final halt, that switches this LED off. No more doubts or time waste trying to figure out when it is the right time to power off.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .