[clug] how to erase a file

[Eyal Lebedinsky]

This is an md raid6. It is up and healthy but has about 80 files than use
blocks that have a mismatch, probably, because you can only identify the
chunk in error rather than the md reporting the exact block (I think that
internally it checks in much smaller units).

I run a 'check' which tells me that I have bad parities, I identify the
offending chunks and then use debugfs to locate all the files that have
blocks inside these chunks. Naturally this is all scripted...

And no, I do not have copies of everything. The bulk is FTA recordings
that I do not back up (and it will not be a disaster to lose) and I do
not have room to move these aside for a rebuild.

Last time I checked raid6 was *not* attempting to use it's ability to
identify the bad part of the chunk and fix it (as raid6 can). Does it
now? I will do a 'repair' then...

cheers

On 02/09/11 23:15, Paul Wayper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/09/2011 09:25 PM, Eyal Lebedinsky wrote:
>> I want to clear a raid mismatch. I already recovered the data and I now need
>> to write to each block of a list of files (the original bad ones). This will
>> fix the raid mismatch.
>>
>> Simply writing to the file does not guaranty that the same blocks will be
>> written to in the fs - blocks may be allocated elsewhere.
>>
>> If the above correct? Is there a simple way to either write zeroes to a file
>> ot even simply read-then-write-back each block? The disk does *not* have i/o
>> errors.
>>
>> Naturally I can go the long way: delete the files (now all bad blocks are
>> unused) then fill the disk with a large file. But I still want to know if
>> I can do it quicker. Can debugfs do this?
>
> What are you using for your RAID management?  Because really it should be
> handling recovering data, not you.  If you're using md, then what does 'cat
> /proc/mdstat' say?
>
> If a file exists, then overwriting it (i.e. seeking to an existing part of the
> file and writing) will not move the blocks around.  That's the only way you
> can guarantee writing to a particular section of the disk without using
> low-level system calls or other great magicks.
>
> If you've got known good copies of the files elsewhere then it may be easier
> to blow away the entire RAID structure and restart it from scratch, so that
> it's synchronised, and then reload the data - depends on how much is on and
> how much is off your RAID.  But really, messing around with the disks
> underneath a RAID is like trying to replace a wheel while driving the car -
> possible but fraught with peril.
>
> Trust your RAID management and the people who wrote it :-)
>
> Have fun,
>
> Paul
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1ShUkACgkQu7W0U8VsXYI1cQCgkCqJCdlW16DBjjCOnqcPazaJ
> IK8AoKJQ08+T1RGfCfinWoktUUf5QgBm
> =ZhQx
> -----END PGP SIGNATURE-----

-- 
Eyal Lebedinsky	(eyal at eyal.emu.id.au)