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)

Hugo did warn us that there would be problems because old versions of certain bits of code were shipping. This counted for both the player software and Mike's builder image. I can only assume that these were the kind of things he expected might happen.

Mike and/or Hugo, if this is the case, is there any chance we might see a corrected builder image any time soon?

___________
Tony Fabris

Greetings!

Hugo did warn us that there would be problems

Oh, don't get me wrong - I have no concerns or have any problems with the folks at empeg at all. Far from it! I just wanted to relay the information on, because I know a number of other people were looking at the larger drives, and that this might be useful debug information as well.

I probably will not have a chance to work on this until later this week at the earliest. My thoughts (at the moment) are that I will need to rebuild the system, perform a more vigorous stress test, and perhaps have to log the uploads. That is the only truly ghastly thought...

Paul G.
SN# 090000587 (96GB Smoke)

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... }

You should read the above as "fsck.ext2 received error 'is a directory' while trying to open /drive1". I'd guess you second drive was not mounted at this point so all fsck sees on /drive1 is an empty directory.

Borislav

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?

The data generated by an FSCK on even a small drive is often too big to fit in the memory space of a Mark II. The player issues "swapon /swapfile" before running fsck, and so should you. Do "swapoff /swapfile" afterwards.

That error from "fsck /drive1" is exactly what I'd expect to see if /drive1 isn't mounted (though the wording is extremely off-putting). Try naming the partition device instead: "fsck /dev/hdb4" (for drive 1; drive 0 is /dev/hda4; on Mark I's drive 1 is /dev/hdc4 IIRC).

Peter

Greetings!

Thanks for the help! I was not aware of the swapon / swapoff, and that gave me a clean FSCK of drive0. I am running it on drive1 now. The drive1 file system was mounted, but still gave that error. The FSCK I am running now was done on the devicename, and seems to be proceeding.

That is one scary looking error! Last time I saw superblock problems on a UNIX box was with Solaris 2.6, and I was backing up and rebuilding the box for far longer than I care to remember...

Hopefully, the FSCK will stabalize things a bit. Meanwhile, I took the precaution of getting emplode csv dumps at a few steps in the process. I will compare these to see if I can find out what went missing, if there was any pattern, etc.

=====

The FSCK came back clean on both drives. The csv dumps were too few and far between to be of much good. I will start taking snapshots, and uploading any missing files.

Paul G.
SN# 090000587 (96GB Smoke)

Edited by pgrzelak on 31/07/01 01:26 PM.

I currently have a 12GB and a 20GB in my Mk. II. I am looking at replacing the 12GB with a 30GB (all IBM's if that makes a difference) and was wondering if I should expect to run into any of these problems because of the drive size?

Any clue yet why some of your song went missing?

Getting nervous, I've been building this database for nearly 10 months now, and I'd lose myself if everything got currupted....

32GB (JUST UPGRADED!) Mk. II BLUE
Detroit, MI USA
www.PfeifferBeer.com

Greetings!

I never found out (for certain) what happened. I suspect it had nothing to do with the empeg or the drives, though. All of the missing songs came from two specific CD-R archives. (I encoded all of my CDs while on the waiting list for the empeg, and burned them to CD-R.) There were errors on both of the CD-Rs that songs were missing from. Normally, I copy to hard drive before emplode, but for these two, I did not. I am guessing that they just didn't sync.

I have not had any replication of this problem, or any problems since.

The issue with the disk builder did seem to happen to me. Even if it did, the 30 is within its normal range, so you should be OK.

[disclaimer] Of course, always back up your data before doing any hard drive upgrade... [/disclaimer]

Paul G.
SN# 090000587 (96GB Smoke)

[sigh]What I would do for an automatic backup feature....[/sigh]

I used Displayserver's backup, but it locked at 4GB...

32GB (JUST UPGRADED!) Mk. II BLUE
Detroit, MI USA
www.PfeifferBeer.com