On 10/05/2016 07:41 AM, Carlos E. R. wrote:
This is now normal practice with modern disk drives and is taken care of by the on-baord electronics so that the computer operating system sees an unblemished linear array of sectors no matter how they might be organized at the physical level.
XFS is adding checksums for at least metadata sectors, and they are considering data checksums, so that file integrity is guaranteed. Btrfs I think is going a similar route, after all, they share several devs.
That is serving quite a different purpose. The purpose of the drive's on-board electronics implementing sector look-aside is to, as I said, present a 'clean disk' to the device drivers of the OS. The file system sits above that. Guaranteeing file integrity is about facing different problems. part of the transition from V6 UNIX to V7 UNIX, for example, was to treat the handling of the metadata of the file system differently, simple that the file system of that time was. Writing the structural and the inode information before the data information enabled FSCK to recover file system problems, problems that HAD NOTHING WHAT TO TO WITH THE INTEGRITY OF THE PHYSICAL DISK ITSELF. In a more modern context, different file systems address this in a different way, treating metadata and structural information different from content data, each in their own way. Some permit the metadata to we written to a separate device! For the most part, this is not about the integrity of the physical disk, though that might be a benefit in some ways, though given the ways a modern disk can fail I doubt it. It is about abuse. its for situations where the system crashes, perhaps a power-out, perhaps a wiring fault or disconnect, so that a FSCK can do a recovery. Or better still, the file system can recover itself without an explicit FSCK. Yes it is possible that a disk starts to fail. Its possible that it develops more bad sectors than the are allowed by the reserved look-aside allocation. it is possible that the disk ages or that the atmospheric sealing fails and dust gets in and the error rate skyrockets. Personally I don't think the kind of file system checks you describe or refer to will be much use when that happens. I say this because I have had that level of catastrophe happen and it basically causes the disk to become unresponsive at a more fundamental level. These integrity checks are good and useful, but they serve a different a different purpose. Conflating the two purposes is not merely sloppy thinking but will end up in wasted effort and perhaps even misguided application. All of this is quite beside the point and has noting to do with the stated object of a "Reliable way to backup hard drive before clean install". We've offered many ways to do that and you keep bitching about errors in TARZ. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org