I want to detect silent corruption of block devices similar to how BTRFS does that for files. I'd even like to do that below BTRFS (and disable BTRFS's native checksumming) so that I can tweak more parameters than BTRFS allows. DM-Integrity seems like the best choice and in principle it must be doing the same thing as BTRFS. The problem is that it's incredibly, unusably slow. While sequential writes on BTRFS are 170+ MiB/s (with compression disabled), on DM-Integrity they're 8-12 MiB/s. I tried to match DM-Integrity parameters with BTRFS (sector size, hashing algorithm, etc) and I tried lots of combinations of other parameters (data interleaving, bitmapping, native vs generic hashing drivers, etc). The writes were asynchronous, but the speed was calculated based on the time it took for writes to be committed (so I don't think the difference was due to memory caching). Everything was on top of a writethrough Bcache, which should be reordering writes (so I don't think it could be BTRFS reordering writes). I can't think of any other reason that could explain this drastic performance difference. I'm using Debian 11 with a self-compiled 6.0.12 Linux kernel and sha256 as my hashing algorithm. My block layers are (dm-integrity or btrfs)/lvm/dm-crypt/bcache/dm-raid. **Is there a flaw in my testing? Or some other explanation for this huge performance difference? Is there some parameter I can change with DM-Integrity to achieve comparable performance to BTRFS?**

I've heard about the Scrub of Death. However one can disable checksumming in ZFS datasets. If so, will that make the situation safer for a system that's not using ECC RAM? I'm not thinking of a NAS or anything like that - more of a workstation deployment with a single drive just to use the ZFS volume management and snapshots (and no need for fsck) benefits. I don't want to use redundancy even. Will a bad memory location still completely destroy my storage if I disable ZFS checksums?

Environment: Debian Bullseye, up to date at the time of writing, nvme-cli 1.12 I am totally new to NVMe and currently try to configure an NVMe SSD correctly. As far as I can tell, I don't need metadata, but **I would like to use the T10-PI protection information.** I have got two questions regarding this subject: **First, I'd like to know how to find out whether that protection has been enabled for a certain device or namespace at all.** I know that I can enable or disable the T10-PI when formatting the device or namespace, but I can't figure out how to get its current status. I have read a good part of the manual pages of the various nvme commands, and also have tried to make sense of the NVMe specification to a certain level, but to no avail. I just seem to be unable to spot it. I am having that problem only with that specific setting; with other settings that are of interest to me, it didn't take too long to find out how to read their current status or value. **Second, I am not sure how to enable that protection.** Theoretically, and from reading man nvme-format, it is clear. I just have to add the -i parameter to the format command to have something like that: nvme format /dev/nvme0 -l 3 -i 1 The disk in question provides 6 LBA modes, mode 3 being the one I want: 4096 bytes per sector, no metadata; hence the -l 3 parameter. -i 1 turns on the T10-PI. When I issue the command above, it gets executed without error message. Afterwards, smartctl -x /dev/nvme0 shows that the current LBA size is now 4096; nvme id-ns /dev/nvme0n1 confirms that mode 3 is in use as expected. So far, so good. But the following is very suspicious: root@gaia ~/scripts # nvme list Node SN Model Namespace Usage Format FW Rev ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- -------- /dev/nvme0n1 PHFT640100G7800CGN INTEL SSDPEDMD800G4 1 800.17 GB / 800.17 GB 4 KiB + 0 B 8DV10171 Under Format, it shows 4 KiB + 0 B. Why? As far as I have understood, the T10-PI needs at least 8 bytes of metadata per LBA. Therefore, I am unsure what actually happens. Does nvme format /dev/nvme0 -l 3 -i 1 just leave the PI disabled (because there is no metadata, and therefore no space for it)? Or is the PI enabled, but nvme list shows only the "real" metadata size (not including the "implicit" bytes which are needed for the PI)? Do I need to use -l 4 instead of -l 3 with nvme format? -l 4 means 4096 bytes LBA size + 8 bytes metadata. If I need to use -l 4, why does nvme format -l 3 -i 1 not throw an error due to wrong command line parameters (we can't turn on T10-PI if we don't have metadata)?

I found several places suggesting to use btrfs under mdraid (mdadm) or LVM Raid. But nobody expands on how that works when you have data checksum issues! My main concern of not using btrfs native raid, is that brtfs have native data checksum. And if I ever have a problem on any of those setup, the two bits diverging will be outside of brtfs domain (either on dmcrypt, or lvm or dm-raid, etc)... How do I go about "fixing" it? Despite the amount of opinions to not use btrfs raid, I could not find good articles on actual alternatives. My Goal is to have any Mirror, Data integrity/checksum (btrfs or otherwise), and snapshots (for the goal of making incremental remote backups over ssh). Encryption is not required, but not a problem either. Also btrfs is also not required, i might do with ext4 after looking at the options that already cover all that before the fs. This is about late boot data drives, not root partition. (Also, note that LUKS+integrity can always be replaced with plain dm-integrity. Just covering 2 cases at once) option 1: 2 HDD -> mdadm raid1 -> LUKS+integrity -> btrfs Option 2 : 2 HDD -> LUKS+integrityx2 -> mdadm raid1 -> btrfs Option 3: 2 HDD -> LVM PVx2 -> VGx1 -> LVx1 raid1+raidintegrity -> btrfs Option 4: 2 HDD -> LUKS+integrityx2 -> LVM PVx2 -> VGx1 -> LVx1 raid1 + raidintegrity -> btrfs Option 5: 2 HDD -> LVM PVx2 -> VGx2 -> LVx2 linear -> mdadm raid1 -> btrfs Option 6: 2 HDD -> MBRx2 -> partitionx2 -> dm-integrityx2 -> mdadm raid1 -> btrfs Option 7 : 2 HDD -> mdadm raid1 -> dm-integrity -> btrfs ...Many, many more combinations! Does any of those non-btrfs raids/integrity will help me deal with btrfs checksum complaining about data integrity mismatch? Or the other way, if mdadm have a /sys/block/mdX/md/mismatch_cnt and I need to pick one of the two HDDs in a RAID1, will brtfs data help me deal with it? (pls, don't suggest openzfs, already had too many questions closed for "Y for X questions" reasons :)

How to accelerate re-syncing large file (>3 TB) which got few of its blocks changed (< 1 GB) with rsync. AFAIK, rsync will do checksum comparison between src/dst blocks to find the differences and then sync them. Is there a way to increase concurrency at the checksum comparison stage to accelerate the sync?

I wish to verifiy a GrapheneOS release I downloaded. This OpenBSD's signify looks like more secure sha512sum. I did not fully understand it. This is what I did: $ brew install signify-osx $ ssh-keygen -Y verify -f allowed_signers.sig -I contact@grapheneos.org -n "factory images" -s tangorpro-factory-2024071200.zip.sig < /Users/me/Downloads/tangorpro-factory-2024071200.zip Could not verify signature. $ ls -lrt total 16 -rw-r--r-- 1 me staff 144 Jul 17 10:13 allowed_signers.sig -rw-r--r--@ 1 me staff 310 Jul 17 10:15 tangorpro-factory-2024071200.zip.sig $ cat allowed_signers.sig untrusted comment: verify with factory.pub RWQZW9NItOuQYMZY8ZMX9VX4hfy54df7Pt3Yh1qEWTyRlQKH4PdteqeKUk9jljywlcCl8nzKJAj75F70Y5FTsAK4cw2aV+CZcAA= $ cat tangorpro-factory-2024071200.zip.sig -----BEGIN SSH SIGNATURE----- U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAghSD+bkKg/zdvSt9ILNhJUDhzDi Kvj2KjkY+jFuDF0kQAAAAOZmFjdG9yeSBpbWFnZXMAAAAAAAAABnNoYTUxMgAAAFMAAAAL c3NoLWVkMjU1MTkAAABApKkue2E4mce5NMqalNZq4ERyZcte1rECYxy7KK9BqwwTX1y4gH Yc0wwNOd9mTwGAMimJWWw2+23biUFWW5kpBg== -----END SSH SIGNATURE----- The error Could not verify signature and signify is not yet documented in internet.

I've added integrity checksum to my root LVM volume using

command: ~# lvconvert --raidintegrity y --raidintegritymode bitmap ... Is there a CLI syntax to get info/details related to dm-integrity?

I currently try to use dm-integrity to run in standalone mode. For that I install a plain ubuntu server 20.04 in a virtual box VM. In the next steps I create the dm-integrity device, a ext4 filesystem and mount it: integritysetup format /dev/sdb integritysetup open /dev/sdb hdd-int mkfs.ext4 /dev/mapper/hdd-int mkdir /data mount /dev/mapper/hdd-int /data echo "/dev/mapper/hdd-int /data ext4 defaults 0 0" >> /etc/fstab **NOTE:** For simplification I use /dev/sdb instead of /dev/disk/by-id/. Now I reboot and see, that the device /dev/mapper/hdd-int does not exist and therefore the mount to /data failed. Now my Question: How can I permanently persist the information of the dm-integrity device, so that the mount after a reboot is already there? Should create a line in /etc/fstab? Or is there another config file?

I have: - A checksum.txt file which contains many lines of checksums of single files from a mountpoint in a huge directory, which mounted and then it disconnected, thereby not finishing the checksum.txt (partial checksums) - localchecksums.txt full checksum list, containing thousands of lines of SHA256 checksums with filenames etc. I would like to: - Compare the remote mount checksums and local ones with sha256sum -c checksum.txt localchecksum.txt or similar, but: 1. I don't want to go through gigabytes of data again to get the remaining hashes 2. I don't want to restart the whole process for checksum.txt I generated the list by using find to recursively find single files and exec sha256sum on them. It is possible to get the remaining hashes by comparing the two files or somehow continue checking the checksums by reading the checksum.txt file and only calculating checksums for unchecked files. The problem with the first approach is that the order is different in the files. The second approach sounds good but I don't have any idea how to start with that. #### Sample of any of the checksum files:

8e2931cc1ad3adc07df115456b36b0dbd6f80f675e0a9813e20ad732ae5d4515  ./folder/8ggSHp5I7hNEl3vDCbWv6Q/wA-KzXIh1Ce3G93s20X24v_4vUeywBe3mXPhGjPt_Lg/cRf8KgbqIsqwbon3DX3PN1-oV6_Nr9Baeymaw-ZJw00
37d2dfe2315cc401536329e3fbe421384bbb50c656c3dbeb42798e5666822e6c  ./folder/8ggSHp7I7hHEl3vDCbWv6Q/wA-KzXIh1Ce3G93s2oX24v_4vUeywBe3mXPhGjPt_Lg/V02s6HKhyJ9Nyd2jQtSjWg
d0e9b95065a264db0d372ccace5d3a72f38f74ca7b44da4794dae23c91e18e57  ./folder/8ggSHp7I7hNxl3vDCbWv6Q/wA-KzXIh1Ce3G93s2oX24v_4vUeywBe3mXPhGjPt_Lg/U3fhBugX6pexYzh6qGKlW7lYWsFShWH7JwN9fmU8ay2lLZkciH2sXsiGbmIc97iJ
44a5fe29063e472857bb9a1929af06a32bb4b2394630f80c2dc732fd662620bc  ./folder/8ggSHp7I7hNEc3vDCbWv6Q/wA-KzXIh1Ce3G93s2oX24v_4vUeywBe3mXPhGjPt_Lg/gTrqUL4ZjWTWMl6BcjfwUe5bBDatscwUoYY9IFQDztc

I'm trying to check the integrity of a set of downloaded files using sha256sum. I cryptographically signed a digest file (named SHA256SUMS) with PGP. I create the file by recursively calculating the checksums of all the files in & under the current directory with

find . -type f -not -name SHA256SUMS -exec sha256sum '{}' \; >> SHA256SUMS

I can now verify the integrity of the files by (after checking the signature of the digest file, which is omitted from this question for simplicity) executing:

sha256sum -c SHA256SUMS

The above command will exit non-zero if any of the files in the digest file have a different contents from what's stored in the digest file. However, it will *not* exit non-zero if there's some new file that's not listed in the digest. I couldn't find any options in sha256sum to fail if there's an unexpected file. How can I verify the integrity of a directory recursively using sha256sum, including failing on unverified files?

Assume an rsync --recursive --ignore-existing foo bar copy command was being run for a large directory tree named foo, but that that command got prematurely interrupted. For example, because of a sudden power failure on the target machine. Running the above command again can save a lot of time for any files/dirs already *fully* copied to the destination bar. But what about any file(s) that was right in the middle of being copied? Presumably, that file exists at the destination in an incomplete/broken state? Having it simply ignored as a "file that's already done" would be very undesirable, of course. Does rsync handle this (extremely run of the mill) scenario intelligently without being directed to do so? (If so, how?) Or does it only do so if specifically instructed by means of more or different flags? Frustratingly, neither the man page nor any vaguely related questions or answers on this site seem to address this very important detail in a clear way. (Sorry if I just didn't look very well.)

I'm trying to synchronize literally thousands of files of various sizes and I would like to have a 1:1 copy of the files. That means that already present files should be checked for their integrity and if there's a wrong checksum, the file needs to be overwritten. A so-called delta transfer is only necessary at this point because of the partially failed transfer. Apparently my mount is kinda unstable and it fails after 300-400GB of transfer using cp or rsync. I did the following before this: 1. I mounted the storage, and did cp -r src dest, it failed after like 300GB because the mount dropped and it errored out (don't have the error anymore apparently) 2. I mounted the storage again and did rsync -aP src dest, it failed after like 400GB with rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7] because the mount failed again. Considering the file size it probably overwrite most of the files. 3. I checked my kernel log and found nothing (sudo dmesg) I found a reconnect flag for my mount, but it would not be instant. - There's a rsync flag named -c which calculates the checksums, but does it do a so-called delta transfer too or do I need to add more flags? How could I best fix this problem at hand? # UPDATE 1 Correct me if I'm wrong but I think the issue at hand was that the storage had the owners and groups of different users and groups than in rsync. To elaborate: cp -r copied the files and changed their ownership and group ownership to the user copying, whereas rsync seems to copy the file 1:1 with the same user and group ownership... That's probably why the transfer was overwriting old files...

I'm using dm-integrity on this drive using cryptsetup directly I formatted it with cryptsetup luksFormat --hash sha384 --cipher aes-xts-plain64 --integrity hmac-sha1. After a while I thing some data got "corrupted". The disk also maybe failing, but I'm able to open it with luksOpen with no problems. I will replace the disk but I need the data it have. So I need a solution of maybe recalculate the checksum in the area that is reporting integrity error so I can open the disk normally Here is the full dmesg log.

[sex jan 27 17:10:20 2023] usb 1-6: New USB device found, idVendor=174c, idProduct=1153, bcdDevice= 0.01
[sex jan 27 17:10:20 2023] usb 1-6: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[sex jan 27 17:10:20 2023] usb 1-6: Product: AS2115
[sex jan 27 17:10:20 2023] usb 1-6: Manufacturer: ASMedia
[sex jan 27 17:10:20 2023] usb 1-6: SerialNumber: 00000000000000000000
[sex jan 27 17:10:20 2023] usb-storage 1-6:1.0: USB Mass Storage device detected
[sex jan 27 17:10:20 2023] scsi host16: usb-storage 1-6:1.0
[sex jan 27 17:10:21 2023] scsi 16:0:0:0: Direct-Access     ASMT     2115             0    PQ: 0 ANSI: 6
[sex jan 27 17:10:21 2023] sd 16:0:0:0: [sdh] Spinning up disk...
[sex jan 27 17:10:22 2023] ..ready
[sex jan 27 17:10:23 2023] sd 16:0:0:0: [sdh] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[sex jan 27 17:10:23 2023] sd 16:0:0:0: [sdh] Write Protect is off
[sex jan 27 17:10:23 2023] sd 16:0:0:0: [sdh] Mode Sense: 43 00 00 00
[sex jan 27 17:10:23 2023] sd 16:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[sex jan 27 17:10:23 2023] sd 16:0:0:0: [sdh] Attached SCSI disk
[sex jan 27 17:14:41 2023] sd 16:0:0:0: [sdh] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=1s
[sex jan 27 17:14:41 2023] sd 16:0:0:0: [sdh] tag#0 Sense Key : Medium Error [current] 
[sex jan 27 17:14:41 2023] sd 16:0:0:0: [sdh] tag#0 Add. Sense: Unrecovered read error
[sex jan 27 17:14:41 2023] sd 16:0:0:0: [sdh] tag#0 CDB: Read(10) 28 00 00 01 db f0 00 00 f0 00
[sex jan 27 17:14:41 2023] critical medium error, dev sdh, sector 121840 op 0x0:(READ) flags 0x4800 phys_seg 8 prio class 2                                                                     
[sex jan 27 17:14:42 2023] device-mapper: integrity: Error on reading journal: -5
[sex jan 27 17:14:42 2023] buffer_io_error: 6 callbacks suppressed
[sex jan 27 17:14:42 2023] Buffer I/O error on dev dm-19, logical block 75185344, async page read                                                                                               
[sex jan 27 17:14:42 2023] Buffer I/O error on dev dm-19, logical block 75185344, async page read                                                                                               
[sex jan 27 17:14:42 2023] F2FS-fs (dm-19): Unable to read 1th superblock
[sex jan 27 17:14:42 2023] F2FS-fs (dm-19): Unable to read 2th superblock

If I try to mount the device I get the following error "impossible to read superblock on /dev/mapper/sdh." I think dm-integrity is not letting me to open the device without correcting the integrity error first. If I try to use fsck I get the following error:

e2fsck -b 32768 
e2fsck: Input/output error while try to open /dev/mapper/sdh

I'm looking for an easy solution to protect against random bit flips (so-called bit rot) of data stored on various drives. They are not disk *arrays*, just single disks, that I backup once a week. So I'm not looking for *redundancy*, but for *file integrity* -- i.e. I want to know if my files that I haven't accessed in a long time got randomly damaged or not, and hopefully repair them if possible. Please note that I want a generic solution, I'm specifically *not* looking for a filesystem like ZFS or btrfs (which I'm already aware of), partly because they have way too much overhead just for checksumming, and they're too complex / unstable (btrfs case). It doesn't have to be an *automatic* thing. That is, if I have to run a command to generate checksums (and maybe recovery) for new written files, that's fine, but it should be simple to use, not something like manually storing checksums and verifying and then copying the bad files back etc (which I'm doing already, that's why I ask for something simpler, less manual). At a glance, SnapRAID seems to do what I want, except it's made for disk arrays, which is my problem. I *think* that it could work with just 1 data disk and 1 parity disk, in which case the parity disk will probably be a *mirror* (backup) of the data disk, but I'm not sure. Other than that it does what I need: checksumming files, ability to verify this, and even repair them from the backup (parity). I'll *still* run a weekly backup on external media, but this local backup needs to be less manual because it's starting to be a pain to manage. Are there other tools like SnapRAID which are made for just 1 data disk or filesystem that they protect with automatic checksumming/backup, or should I just use SnapRAID? Does it work fine with just 1 disk? Because it uses a *parity disk* for the backup, I'll have to completely wipe my local backup disk before using it with SnapRAID, so I'm hesitant to just "test" it for myself without confirmation. One downside to this is that the parity disk will not be accessible as a normal disk, even though in this case it's not *really* a parity disk but just a mirror. So if there's another similar easy-to-use tool for dealing with just backing up **and integrity of files** of 1 disk instead of a disk array, I'd like to know. Thanks.

I work on an ext4 filesystem. I have doubts about the accuracy of a directory entry regarding the description of a file that I have copied from an NTFS filesystem and that might have spanned some bad sectors (but I am not sure). I now believe the file might have been truncated when copied from its source but that the directory entry in the ext4 filesystem does not reflect the now-truncated file size but rather kept the information of the file size from the NTFS filesystem table. I don't know if such a situation is possible, but I want to be sure the file is not truncated (unfortunately the file is in a proprietary format and I cannot just open the file to check it). I run a dd command on the file toward /dev/null and it seemed to have "copied" as much as the original file size. However, I am now wondering whether the dd command used the meta data about the file size from the inode table, which would defeat the goal. - Can it be that after copying a file the inode table doesn't reflect the real size of what was actually copied? (I think I just did a click-and-drag in a file explorer)? - Is using the dd command a good option? - Are there metadata in the ext4 filesystem that could be used to independently check the size of the file and thus accuracy of the information in the inode table (I think about data integrity fields)?

I read about the MD5 collision and that MD5 is not reliable anymore, however, I'm curious if that applies when we check the integrity of files. I've noticed that tools such as the FLAC/metaflac (Free Lossless Audio Codec) still relies on MD5 for checking the data integrity of music files.

I've been trying to enable the integrity feature on my new LVM2 volumes. I use a command like this to create the lv:

sudo lvcreate --type raid1 --mirrors 1 --size 20g --raidintegrity y --name RAID MY_VG

The lv appears to be created successfully and I can see it building itself in the Cpy%Sync output of lvs. All seems to go well and it eventually reaches 100%. I can create a filesystem (been playing with xfs and btrfs), I can mount it, write to it and the volume appears to be working flawlessly. I updated fstab and it mounts and unmounts smoothly with a simple sudo mount -a for example. #### Then I reboot and the logical volume is never auto activated So fstab cannot find the filesystem to mount. I can fix this manually with a simple sudo vgchange -ay MY_VG and then a sudo mount -a but something seems wrong because... #### This is only a problem for Logical Volumes with Integrity enabled. I created a second logical volume without integrity (and that is the only difference):

sudo lvcreate --type raid1 --mirrors 1 --size 20g --raidintegrity n --name RAID_TEST MY_VG

And after reboot RAID_TEST is activated and available to be mounted immediately, but my original logical volume with integrity (named just RAID) is still deactivated at boot. So because this test LV is activated I know there is nothing wrong with the PVs nor the VG. The issue has to be with the LV configuration with integrity but I can't find any docs that suggest I am doing anything wrong. I have reproduced this on 2 different servers with various different combinations and the results are always the same and its only the volumes with integrity enabled that behave this way and never auto-activate. Zero obvious errors in system logs, journalctl, nor systemctl status of any lvm units. What is going on? I can see zero errors with the devices or lvm when I check journalctl. The only output all looks normal (and its the exact same log messages for every logical volume and volume group in my system regardless of whether its a volume with integrity enabled). At this point I am wondering if integrity is actually a ready-to-use feature of LVM2. My experience has been extremely janky with very very poor documentation. The man pages for lvchange with respect to integrity features conflict with the raw source code of lvchange (which I eventually had to go read the flipping source). The source code also contradicts the RedHat documentation around lvm integrity . None of that explains why this is happening though. Can anyone help? It would be very appreciated. At this point it feels like I need to abandon LVM if I want integrity protection.

mv is implemented as a simple [rename()](https://pubs.opengroup.org/onlinepubs/000095399/functions/rename.html) whenever possible, falling back to copy-then-delete whenever renaming doesn't work. In practice ([but not in theory](https://github.com/coreutils/coreutils/blob/3a1c328cd55f427a74f16cda8513bedb7c153fd8/src/mv.c#L192-L202)) , these two cases correspond to source and destination being on the same or on different filesystems, respectively. **My question:** Does mv, as defined by the POSIX standard and implemented as part of the GNU coreutils, make any guarantee that in the latter case (i.e. rename not possible, fall back to copy-then-delete), filesystem caches are flushed (in the sense of [sync](https://linux.die.net/man/8/sync)) between the copy and delete operation so that disconnecting the destination filesystem at just the right moment won't lead to data loss? **What I've found so far:** The [POSIX spec for mv](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html) says that >termination at any point shall leave either source_file or the destination path complete which would suggest "yes", but then I'm not sure whether disconnecting a filesystem would be classed as simple "termination" or not, whether such statements in general only apply to the "surface" filesystem state, and so on. There is a [Hacker News comment](https://news.ycombinator.com/item?id=11804364) answering "no" but not citing any sources. Maybe the question is actually ill-defined because [POSIX sync()](https://pubs.opengroup.org/onlinepubs/009695299/functions/sync.html) does not even guarantee *completion* of the flush, only triggering it, so there is no way to implement a "completely safe" copy-then-delete across filesystems anyway? I tried to find out how it's actually implemented in [GNU coreutils' mv's source code](https://github.com/coreutils/coreutils/blob/3a1c328cd55f427a74f16cda8513bedb7c153fd8/src/mv.c#L153) , but before I waste any more time on this and in the interest of anyone else with the same question, I thought I'd ask here, too.

Can I check the integrity of the archive without decompressing it as the archive is 64GB. It is a backup of my old laptop and before i format my old laptop I wanted to verify the backup but it will take too long to decompress and verify. So is there a faster way to do so?

I run commands: tar -cf myArchive.tar myDirectory/ gzip myArchive.tar then I copy the file over a lot of unreliable mediums, and later I unpack it using: tar -xzf myArchive.tar.gz The fact that I compressed the tar-ball, will that in any way guarantee the integrity, or at least a CRC of the unpacked content?