7

I have 2 storage devices; classical slow HDD (750GB, /dev/sda) and faster SSD (128GB, /dev/sdb). Currently I have installed Ubuntu & Mint on same btrfs partition on SSD (/dev/sdb5). My btrfs pool consists of /dev/sdb5.

What I want to achieve is data replication on HDD while keeping SSD performance: Something like this:

For read case it would be ideal for procedure to go like this:

  • read from SSD
  • check checksum
  • if it verifies.. awesome, give me the data
  • if not, fetch data from HDD and perform error correction through duplicate data

I'd manually run (some tool I'm not sure which one... btrfs check --repair perhaps?) every month or so to check HDD checksums and correct them via SSD data against bitrot.

For write case:

  • write to SSD
  • sync to HDD when write requirements are low, thus not slowing down the system.

Is this possible and how would I do it?

Bottom line is, I like btrfs and would like it to duplicate data across HDD & SSD drive automatically while keeping SSD excellent performance.

Using SSD as write cache is not an option since it's missing data duplication and security.

Gilles 'SO- stop being evil'
  • 829,060
nmiculinic
  • 365

1 Answers1

4

Assuming your SSD is faster for writes (and not just for reads), then there's an easy way to set this up with Linux's RAID subsystem. Say you're going to replicate /dev/sda1 (HDD) and /dev/sdb1 (SSD):

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 --write-mostly --write-behind=1024 /dev/sda1

--write-mostly means that the preceding device(s) will be preferred for reading, while the following devices will only be written to most of the time. --write-behind means that the write-mostly devices are allowed to lag behind; the parameter determines how large the write buffer is. You may want to tweak the write-behind parameter based on performance on your machine.

If you want to use your existing volume, you can convert it to RAID-1 with superblock format 1.0.

Drives already include their own integrity checks, so there's usually not much use for another one on top. The main problem with drive failure is data that becomes unreadable, not data that becomes corrupted. I don't know what the relative undetected error rate is for SSD and HDD, but I suspect that it's about the same (and thus not SSD vs HDD but between the particular devices), so there's no reason to assume that the data read back from HDD is more accurate. Btrfs and ZFS have optional filesystem-level integrity verification if you want that.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • Thank you for your answer, I had wrong perception about usual drive data corruption problems.

    Why does btrfs includes checksums in its metadata for file then?

     – nmiculinic Dec 23 '15 at 16:11
  • @lpp btrfs includes optional checksums because checksums only lower the probability of undetected errors, they don't eliminate it completely (e.g. a 32-bit checksum means that 1 in 2^32 errors goes undetected. Drives aren't the only source of error though; if you don't trust your disk then you absolutely shouldn't trust your RAM. I don't think using btrfs checksums on a machine without ECC RAM makes sense, for example. – Gilles 'SO- stop being evil' Dec 23 '15 at 16:38