On 12/12/13, Chris Mason <c...@fb.com> wrote: > For me anyway, data=dup in mixed mode is definitely an accident ;) > I personally think data dup is a false sense of security, but drives > have gotten so huge that it may actually make sense in a few > configurations.
Sure, it's not about any security regarding the device. It's about the capability of recovering from any bit-rot which can creep into your backups and can be detected when you need the file after 20-30 generations of backups which is too late. (Who keeps that much incremental archive and reads backup logs of millions of files, regularly?) > Someone asks for it roughly once a year, so it probably isn't a horrible > idea. > -chris Today, I've brought up an old 2 GB Seagate from the basement. Literaly, it has been "Rusted". So it deserves the title of "Spinning Rust" for real. I had no hope whether it would work, but out of curiosity I plugged it into a USB-IDE box. It spinned up and wow!; it showed up among the devices. It had two swap and an ext2 partition. I remembered that it was one of the disk used for linux installations more than 10 years ago. I mounted it . Most of the files dates back to 2001-07. They are more than 12 years old and they seem to be intact with just one inode size missmatch. (See fsck output below). If there were BTRFS (and -d dup :) ) at the time, now I would perform a scrub and report the outcome here. Hence, 'Digital Archeology' can surely benefit from Btrfs. :) PS: And regarding the "SSD data retension debate" this can be an interesting benchmark for a device whick was kept in an unfavorable environment. Regards, Imran FSCK output: fsck from util-linux 2.20.1 e2fsck 1.42.8 (20-Jun-2013) /dev/sdb3 has gone 4209 days without being checked, check forced. Pass 1: Checking inodes, blocks, and sizes Special (device/socket/fifo) inode 82669 has non-zero size. Fix<y>? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdb3: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdb3: 41930/226688 files (1.0% non-contiguous), 200558/453096 blocks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html