Greetings!

I finally finished loading the main music library today, and was starting to build my "favorite song" random playlist. I noticed that some (very few, from what I saw) of the songs were absent. The playlists were present, but blank. Example: Rush -> Caress Of Steel and Yes -> Tales From Topographic Oceans were still there, but there were no mp3 files present. I know I uploaded them.

I have passed through 2 full disk check syncs while uploading data. Both seemed to take a while, but that was not unexpected given the amount of data. Both concluded without visible error. I noticed, though, that I seemed to do two detailed checks in a row for two consecutive syncs. I thought it might be breaking it up over each disk, and I did not remember if this was the case previously.

When I noticed the files missing, I went into developer. There was nothing in either lost+found, but when I went into rwm and ran FSCK, I received the following:

empeg:/bin# fsck /drive0
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda4 is mounted.
/dev/hda4 was not cleanly unmounted, check forced. { probably my fault from rwm }
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
no room for private writable mapping
error: -12
fsck.ext2: Memory allocation failed while retrying to read bitmaps for /dev/hda4
empeg:/bin#

This is a new one by me. I am guessing that the amount of data generated by an FCSK on the larger drives is too big to fit into the memory space of a MarkII(empeg). Any thoughts?

Meanwhile, I tried the same thing on drive1 after performing a hard reset (to make certain memory was clear). I am not at all happy with the results...

empeg:/# fsck /drive1
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /drive1 is mounted.
fsck.ext2: Is a directory while trying to open /drive1 { I don't know what this one means, fsck.ext2 is a file... }

The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

I am now studying up on my FSCK commands to list another superblock copy, but this is not a fun sign. Unfortunately, I am more familiar with Solaris, and the newfs -Nv that I would normally use does not appear to apply here. Even if I could get through the FSCK, I do not know if I would be able to write the results. Does anyone know the linux command to do an FSCK with an alternate superblock?

Now the fun part - is it a bad drive, a bad FS based on the disk builder program, a bad cable (this is the one where the connector was repaired), a bad FSCK that crashed during a sync, etc.

Meanwhile, those people looking at the 48GB drives: you may want to wait. I have not figured out yet if this is because of a dual big drive, or the size of a single drive. You may still run into the memory issue with one drive, but that does not appear to be a data issue. Yet.

In any case, I still seem to be functional at the moment, so I will tread very carefully. I know I will probably have to rebuild / reload (a horrifying thought), but there could be a deeper problem here. Any thoughts or opinions are welcome. Worst case, I could always put my old drives back, but...

Paul G.
SN# 090000587 (96GB Smoke)