Uniquely malformed MBR containing NTFS PBS causes udev spam and constant reads #1207
Comments
|
Please provide |
|
@tbzatek As mentioned I did make a backup of the first 2048 bytes, so for posterity I tried it on a small file attached using a At the moment the issue is not happening right now after I tried to return back to the previous setup as much as I can. But these are the following actions I did:
For now I'm going to leave the system back to that setup and see if the issue crops up due to time, since even with a broken MBR the system works fine. I'll report back if it starts happening again. |
|
Though here's the
|
|
Thanks, the udevadm dumps look fine (e.g. the |
|
@tbzatek Ah, didn't know but good to know otherwise and something I'll probably have to look into myself. I'll see if I could instead recreate the events that led to this situation by using Windows to format a NTFS disk then lazily turn the created partition into BTRFS. |
|
So I went into Windows and tried to recreate the issue with a spare SSD and used HxD to look at the results, but in all the ways I could do in Disk Management did not try to add the NTFS' PBS at the MBR. Mostly the testing process was initialize the disk, add NTFS, then look at it in HxD before manually zeroing out the first handful of sectors before I'd try something else to much of Windows' annoyance. In all cases it would create a MBR stub and/or create the GPT table with nothing unusual; no NTFS PBS. Back on the Linux side I also tried purposefully formatting the whole disk NTFS ( Mildly disappointed that I destroyed the only unique case of a malformed MBR disk that would cause udev spam. Oh well, at least if someone ever encounters a situation like this they would take some solace that they weren't the only one and there would be this issue to supply their working (broken?) case of So at this point it would seem this issue is stalled. |
jarrodsfarrell
changed the title
This issue is missing samples to reproduce as they were inadvertently destroyed. If you came here from a search then kindly engage here and supply samples before doing any partition modification as it may destroy the circumstances that would cause this bug.
/dev/sdb1used to be a NTFS filesystem holding games at one point when Windows was the dominate OS on this desktop and later became a BTRFS filesystem by lazily pointingmkfs.btrfsat it. Importantly the games were migrated over. This has been for almost a year.Around this month I noticed my HDD light constantly illuminated and checking
iotopI sawudisksdwriting to the disk at a constant 6-7 M/s. Checkingudevadm monitorthere was a lot ofUDEVandKERNELchangeevents.I did some other debugging steps I found online, but the one that ended up showing something unusual was with
strace. Scanning around the file\353R\220NTFScame up frequently during areadcall. Searching around brought me to a unrelated post about someone having issues with NTFS, then searching up the NTFS structure came across it's Partition Boot Sector. This is when I discovered this disk was still MBR. Usinggdiskto discard the MBR and recreate the partition table resolved the issue with the disk no longer constantly read.Before discarding the MBR, I did make a backup of the first 2048 bytes, sdb.2048-bytes.bin.gz. And running
partedagainst the disk before fixing produced an interesting result, included for the absurdity.Reminder:
/dev/sdb1is actually abtrfsfile system.Extra
/etc/fstabdeclaration:Disk information:
/etc/os-release:The text was updated successfully, but these errors were encountered: