https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242341
--- Comment #6 from Tomasz "CeDeROM" CEDRO <to...@cedro.info> --- (In reply to Andrey V. Elsukov from comment #5) Hello Andrey and thank you for your reply :-) = ACTIONS = 1. dd if=/dev/da0 of=/dev/da1 bs=512 count=1 does not copy anything. 2. dd if=/dev/zero of=/dev/da1 bs=512 count=1 zeroes the mbr. 3. dd if=/dev/random of=/dev/da1 bs=512 count=1 randoms the mbr. 4. dd if=/dev/da0 of=da0.mbr bs=512 count1; dd if=da0.mbr bc=512 count=1 does NOT copy the mbr. 5. mdconfig -a -tvnode da0.mbr; dd if=/dev/md0 of=/dev/da1 bc=512 count=1 does put the data into mbr, but still da1 seems to have no partitions!!! = ANSWERS = >> 1. I would like to clarify why I was unable to write to MBR >> (first 512 bytes) of the da1 while there was no problem with >> writhing to the rest of the disk? > How did you know that? Did you compare the first 512 bytes > on both disks after copying? Yes, exactly! I am using `less -f` rather than `bvi` (stalls the OS by loading 128GB into RAM lol) on a large files just to sneak peek the contents. Because after initial failures with DD I did ZERO the whole disk just to make sure its is all clean. Zeros looks like monkeys and you can see with bare eye where are zeros and where not, 512 bytes fits nicely on one screen :-) >> 2. GEOM_PART: integrity check failed (da1, MBR) >> <- could that block / discard writes to MBR silently? > This usually means that parition table's metadata is wrong. > If it is wrong, and kern.geom.part.check_integrity is set, > then GEOM_PART just ignores the partition table. root@0xCFMX4:~ # sysctl kern.geom.part.check_integrity kern.geom.part.check_integrity: 1 Can you please explain in detail what does it mean exactly "ignores the partition table"? I guess here is the problem. If the "partition table is ignored", then why it is silently ignored, writes to MBR goes to /dev/null, reads from MBR does not update disk layout, while it is possible to write to the rest of the disk? Why the whole disk is not locked against writing in a clearly distinguishable manner? Like error return code from DD and error messages in DMESG? If the MBR is corrupt, then high chance of all partitions may be corrupt, write out of bounds may happen, so writing data to such disk would irreversibly destroy data that are stored on such drive. This "ignore" thing makes system incoherent and unpredictable. Here is my proposal for change: 1. Either we allow writing to the WHOLE disk AND the MBR but signal _warning_ the MBR corruption via DMESG when kern.geom.part.check_integrity=1. 2. Or we signal _error_ MBR corruption over DMESG and whole disk is locked against writing with clear error message (i.e. DD writes return clear fail and at the same time we show DMESG error message like "/DEV/XXX disk is write locked because MBR is corrupt. Clear kern.geom.part.check_integrity if you want to write to that disk anyway") when kern.geom.part.check_integrity=1. 3. I know there are some additional flags that may allow writing over "ignored" disk. They are not set by default and kind of unclear where to find them. Definitely not a fix for the current "silent write ignore surprise" until you set them. I guess using the kern.geom.part.check_integrity is good enough to control the situation. Either kern.geom.part.check_integrity=1 and when MBR or GPT is corrupt then WHOLE disk is clearly locked against writing (as explained in point 2 above), or kern.geom.part.check_integrity=0 and we can write over the WHOLE disk even if MBR or GPT seems corrupted because it is not verified. I think number 2 would be the safest choice..? >> 3. Why `dd if=/dev/da0 of=/dev/da1` did copy all disk except the MBR? > How did you know that? Did you compare the first 512 bytes on both disks > after copying? I assume you have disks with different size and GEOM_PART > just rejects MBR on the copied disk, because its integrity check has failed. Exactly, verified them after write. No write to MBR occured, but the whole contents was written. There was no clear error that MBR was not written. This should be signaled with an error and write to the disk should be prohibited as explained above. So you confirm that the write to MBR was silently discared and the whole situation is indeed managed by GEOM_PART. This is exactly the problem I am reporting. Thank you :-) >> 4. Why I was unable to write to MBR from a file but it was possible >> to write that data from a file over md0? > Again, how did you know that? Verification after write :-) = SYSTEM DETAILS = ugen0.7: <Kingston DataTraveler 3.0> at usbus0 umass0 on uhub0 umass0: <Kingston DataTraveler 3.0, class 0/0, rev 3.20/1.10, addr 6> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:2:0: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: <Kingston DataTraveler 3.0 PMAP> Removable Direct Access SPC-4 SCSI device da0: Serial Number BLAHBLAH da0: 400.000MB/s transfers da0: 118368MB (242417664 512 byte sectors) da0: quirks=0x2<NO_6_BYTE> ugen0.8: <Kingston DataTraveler 3.0> at usbus0 umass1 on uhub0 umass1: <Kingston DataTraveler 3.0, class 0/0, rev 3.20/1.10, addr 7> on usbus0 umass1: SCSI over Bulk-Only; quirks = 0x8100 umass1:3:1: Attached to scbus3 da1 at umass-sim1 bus 1 scbus3 target 0 lun 0 da1: <Kingston DataTraveler 3.0 PMAP> Removable Direct Access SPC-4 SCSI device da1: Serial Number BLAHBLAH da1: 400.000MB/s transfers da1: 118272MB (242221056 512 byte sectors) da1: quirks=0x2<NO_6_BYTE> GEOM_PART: integrity check failed (da1, MBR) FreeBSD 0xCFMX4 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-geom@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
