mdtrim icon indicating copy to clipboard operation
mdtrim copied to clipboard

[not a bug, help] - Data written into the file and data on the physical HD do not match

Open newmjw opened this issue 12 years ago • 5 comments

Hi Cyberax,

I'm having an issue with the script, I doubt it requires any changes to it, but this is really the only way I could find to contact you.

I just purchased two of the crucial M4 ssds, and set each partition up in a in a raid 1 with MDADM. As far as I can tell, I did everything right, everything is working, except trim. When I use the hdparm fibmap & read-sector test, I do not see zeros, as I did with my old vertex2.

Looking around online, it appears that this is caused by no support for discard in the raid1 module. There's the thread on LWN about a patch, which you have probably read, but it's not committed yet, and it's probably going to be some time before it is.

I bet if I failed the raid and just operated on each drive one at a time, discard would work. I was going to go about figuring out how to do that, but then I found your script, which looks like a perfectly fine work around until the kernel supports it. I did this with wiper.sh for a few years.. I tried the script, but I get stuck at:

print "Checking misalignment signatures"
for sl in slaves.values():
    slave_offset = sl["offset"]*sector_size
    for rng in trim_ranges:
        for test in rng["test_data"].values():
# snip...
            sector_data = data + ' '*padding + data

            what_we_read = string_at(read_buf+read_buf_offset, sector_size)
            if what_we_read != sector_data:
                print "Data written into the file and data on the physical HD do not match!"
                sys.exit(2)

what_we_read is: empty string sector_data is something like:

Zb45aa627634f4682950f49b4e9e9f8a0


 b45aa627634f4682950f49b4e9e9f8a0A

Any ideas why that would happen and what I can try next to fix it? Is it a hole in the script, or is something horribly wrong with my setup, or even a hardware problem?

Thanks

newmjw avatar Jun 24 '12 03:06 newmjw

Ditto here, would love some direction.

pdf avatar Sep 18 '12 14:09 pdf

The same here. Any idea about this issue?

tomposmiko avatar Jan 13 '13 22:01 tomposmiko

What is the exact model of SSD? I'm going to try and reproduce it. Looks like it's a workaround for 4096-byte-sectors gone wrong somewhere.

Cyberax avatar Jan 14 '13 17:01 Cyberax

Mine: Model Number: INTEL SSDSA2CW120G3
Serial Number: CVPR118100ZU120LGN
Firmware Revision: 4PC10302

Thanks.

tomposmiko avatar Jan 14 '13 18:01 tomposmiko

Similar issue here on a couple OCZ VTX4-25SAT3-64G drives running 1.5 firmware. However instead of an empty string (unless this is an empty string and I am mistaken) for what_we_read (which appears to be the same character length as sector_data), this is what what_we_read contains:

��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

sector_data:

14d5ec6b71184e29bcd6be62702b6b2b                                                                                                                                                                                                                                                                                                                                                                                                                                                                14d5ec6b71184e29bcd6be62702b6b2b

Any updates on the original issue?

persist-zz avatar Mar 19 '13 23:03 persist-zz