2

(This is kind of a followup to the issue I had yesterday where I lost data because of a removal-while-copying)

I already know NTFS doesn't handle an unexpected removal too well. Do the newer Unix-based filesystems like btrfs, ZFS, ext4 or nilfs2 do any better in this regard? Would there be a higher chance of file recovery afterwards?

5
  • unless I'm misunderstanding you (you may want to clarify your question or at least link your prior thread), no, there can be no such thing. its impossible to recover data that never got written to the drive due to the power-loss. you would have to go to the source to find the data. luckilly, reads are generally non-volatile operations, so powerloss during a read should not cause a data loss. Jun 26, 2013 at 11:49
  • Never do a removal while copying. Copy, then remove.
    – LawrenceC
    Jun 26, 2013 at 14:18
  • @ultrasawblade In an ideal world, obviously, but then there are such annoying things as (like pointed out in the title) power failures, software crashes and whatnot which may cause the system to freeze or unexpectedly power-off.
    – user
    Jun 26, 2013 at 14:32
  • 1
    I find it funny that you blame NTFS when after scanning barely 4% of your drive you already ended up with 11000 bad sectors. It wasn't just mere loss of power; the drive was dropped and physically damaged to such a large extent. Also, this article by Raymond Chen might interest you.
    – Karan
    Jun 28, 2013 at 1:58
  • That's pessimistic. Out of 136 million sectors only 18700 are bad so far. I do 'blame' NTFS, I'm not expecting too much in 2013 for a filesystem to cope with a sudden power loss? Though it seems others share my opinion and so have created some of the filesystems mentioned. It was a very small drop, after seeing the results from HDD regenerator so far it doesn't look like physical damage is the symptom.
    – warsong
    Jun 28, 2013 at 8:18

2 Answers 2

3

Removing power from a drive is inherently dangerous. You will most likely end up with corruption, regardless of the file system you choose.

Some file systems are better able to deal with this than others. Some file systems use journaling. For greatest safety, you want a file system which journals both the metadata (e.g. directory entries) and the data, and additionally one which uses write-barriers. This comes with a (sometimes substantial) performance hit.

With data journaling (and appropriate use of barriers), any writes to a file will either succeed or fail. This gives you the best chance of avoiding corruption if you lose power while copying. The file system will still need to be checked and the journal entries replayed or skipped, but this should be fairly fast. Obviously, this will likely leave you in the state where only some files were successfully copied. A tool like rsync or TeraCopy can help you there.

Of the file systems you list, NTFS journals metadata only. ext3 and ext4 offer optional data journaling (at a performance cost) in addition to meta-data journaling. btrfs and zfs use a different approach, copy-on-write, which should offer similar benefits to data journaling. nilfs2 is a continuous snapshotting file-system, but I don't know enough about it to comment on its viability in this use-case.

If you are concerned about data loss during a power failure, you may want to look at a UPS. Some RAID cards allow battery backup as well, which may be useful depending on your specific use-case.

2

ZFS certainly cope with loss of power while copying.

Data intended to be written will be lost during the event if not commited but the previous file data and the overall file system, being transactional, won't suffer and stay clean by design.

2
  • I'd love to see a link explaining how ZFS's copy-on-write ensures this. I don't have enough knowledge to explain it well myself. :) Jun 28, 2013 at 14:22
  • 1
    @ChrisInEdmonton This page would be a good start: c0t0d0s0.org/permalink/…
    – jlliagre
    Jun 28, 2013 at 15:27

You must log in to answer this question.

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