[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Deletion of files from usb-key



Haines Brown wrote:
(...)

3. Decide whether the problem is within a partition or at the level of
   the partition table by zeroing the partition. Unmount the device
   and do (example assumes the device interface is /dev/sdd):

        # cat /dev/zero > /dev/sdd1

or # dd if=/dev/zero of=/dev/sdd1 bs=512 count=1

Those are not the same, the latter only overwrite the first 512 bytes of the partition with zeroes, which will certainly not erase most of the data on the partition (well it shouldn't matter "usually", if you run mkdosfs or similar it will lay out a new filesystem on it; but to get the effect of guaranteed elimination of some existing data, overwriting the whole partition is necessary, so leave out that "count=1" or use the cat variant).

   If this succeeds and you can write a file to the partition, the
   problem would seem to be fixed

Of course before being able to mount the partition again, one has to create a new filesystem (using mkdosfs or similar).

4. If the zeroing of the partition causes I/O errors, then the problem
   is possibly at the partition table level. To wipe the entire device
   clean and start from scratch:

        Unmount the usb-key, unplug and replug it in.

   Then zero the entire drive, removing the partition information:

# dd if=/dev/zero of=/dev/sdd bs=512 count=1

(I'm not sure whether 512 bytes are always guaranteed to erase the whole partition map information or enough of it to convince the kernel and cfdisk that there isn't any. If in doubt, just overwrite the whole /dev/sdd (leave out the "count=1").)

If this fails to eliminate the I/O error, then it is likely the
   entire device is physically broken. On the other hand, if the
device can be zeroed, then do:
        # sync

(Just a note: I said to run "sync" to flush the caches out to the hardware (reads and writes to block devices (like /dev/sdd) are being cached in ram). Possibly that's not necessary anymore with 2.4 kernels, I think (but am not sure) that 2.4 now automatically flushes caches after the last open filehandle to some block device is being closed (2.2 didn't do that). But in any case, an extra "sync" never hurts.)

Christian.



Reply to: