Results 1 to 2 of 2

Thread: Formatted drive still holds files!

  1. #1

    Default Formatted drive still holds files!

    Hi:
    [Suse 10.3] I have a Panasonic DVDRAM drive, SW-9576C with a DVD-RAM cartridge installed. It lives at /dev/hda. It is formatted as a whole disk, with no partitions.

    I deleted a file from the DVD-RAM with the date of 07/15/09, then copied a new version of the same file from HD to the DVD-RAM. The result was that the directory of the DVD-RAM still shows the old file date and size:

    > l cd-rw/test.dvdram.backup.tar # source file
    -rw-r--r-- 1 crcarle users 16394240 2009-08-05 07:19 cd-rw/test.dvdram.backup.tar

    > l /media/dvdram/test.dvdram.backup.tar # dest. file
    -rw-r--r-- 1 crcarle users 16384000 2009-07-15 17:07 /media/dvdram/test.dvdram.backup.tar

    Then I attempted to append data to the end of the DVD-RAM file. This resulted in an IO error, after which the dir of /dev/hda would no longer display.

    I ran # fsck /dev/hda, which said there were errors, but didn't actually list any.

    After checking, the DVD-RAM still behaved the same strange way, showing the 07/15/09 file date even after writing a new file.

    I then formatted the DVD-RAM, mounted it, then looked at the dir. Guess what, all my files are still there!:

    # mke2fs -b 2048 /dev/hda
    mke2fs 1.40.2 (12-Jul-2007)
    /dev/hda is entire device, not just one partition!
    Proceed anyway? (y,n) y
    Filesystem label=
    OS type: Linux
    Block size=2048 (log=1)
    Fragment size=2048 (log=1)
    561152 inodes, 2236704 blocks
    111835 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=540016640
    137 block groups
    16384 blocks per group, 16384 fragments per group
    4096 inodes per group
    Superblock backups stored on blocks:
    16384, 49152, 81920, 114688, 147456, 409600, 442368, 802816, 1327104,
    2048000

    Writing inode tables: done
    Writing superblocks and filesystem accounting information: done

    This filesystem will be automatically checked every 23 mounts or
    180 days, whichever comes first. Use tune2fs -c or -i to override.

    mango3:/home/crcarle # mount /media/dvdram
    # l /media/dvdram
    total 1990424
    drwxr-xr-x 7 crcarle users 4096 2009-07-30 16:49 ./
    drwxr-xr-x 3 root root 4096 2009-08-05 07:18 ../
    drwxr-xr-x 17 crcarle users 4096 2009-06-17 16:43 AutoCAD/
    -rwxr-xr-x 1 crcarle users 1047845 2008-08-06 16:47 bookmarks.html*
    drwxr-xr-x 9 crcarle users 4096 2009-04-23 16:51 eagle/
    -rw-r--r-- 1 crcarle users 36 2007-06-27 10:51 EVEN
    -rw-r--r-- 1 crcarle users 2018713600 2009-07-30 18:51 full.dvdram.backup.tar
    drwx------ 2 root root 16384 2007-06-27 09:55 lost+found/
    drwxr-xr-x 27 crcarle users 4096 2008-08-11 13:27 so-work/
    -rw-r--r-- 1 crcarle users 16384000 2009-07-15 17:07 test.dvdram.backup.tar
    drwxr-xr-x 6 crcarle users 4096 2008-09-25 15:34 ti-dsp/

    # cat /media/dvdram/EVEN
    This side is for even day backups.

    Can anyone explain this craziness? Obviously the media is suspect. But geez, why isn't the OS dealing with the situation more constructively? If I didn't do explicit verifications, I wouldn't have discovered the problem. What may explain things is that the disk actually can't be written to at all. So the contents remain the same and read the same after write attempts.

    The fault is that the OS doesn't consistently detect the write faults. Why?

    Here's another shot of the fsck:

    # fsck /dev/hda
    fsck 1.40.2 (12-Jul-2007)
    e2fsck 1.40.2 (12-Jul-2007)
    /dev/hda contains a file system with errors, check forced.
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information

    /dev/hda: ***** FILE SYSTEM WAS MODIFIED *****
    /dev/hda: 4343/560000 files (0.0% non-contiguous), 578016/1118352 blocks

  2. #2

    Default Re: Formatted drive still holds files!

    Update:

    There are lots of nasties in /var/log/messages:

    Aug 5 08:17:31 mango3 kernel: hda: command error: status=0x51 { DriveReady SeekComplete Error }
    Aug 5 08:17:31 mango3 kernel: hda: command error: error=0x70 { LastFailedSense=0x07 }
    Aug 5 08:17:31 mango3 kernel: ide: failed opcode was: unknown
    Aug 5 08:17:31 mango3 kernel: ATAPI device hda:
    Aug 5 08:17:31 mango3 kernel: Error: Data protect -- (Sense key=0x07)
    Aug 5 08:17:31 mango3 kernel: (reserved error code) -- (asc=0x32, ascq=0x00)
    Aug 5 08:17:31 mango3 kernel: The failed "Write 10" packet command was:
    Aug 5 08:17:31 mango3 kernel: "2a 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 "
    Aug 5 08:17:31 mango3 kernel: end_request: I/O error, dev hda, sector 0
    Aug 5 08:17:31 mango3 kernel: printk: 17963 messages suppressed.
    Aug 5 08:17:31 mango3 kernel: Buffer I/O error on device hda, logical block 0
    Aug 5 08:17:31 mango3 kernel: lost page write due to I/O error on hda

    I think the disk is simply shot. The strange fact remains that the high level commands don't return an error.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •