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