Hi all,

I am jumping back into the empeg community after many years of simple enjoyment of my empeg. Recently I attempted to rebuild my drives as a practice run for a pending 250GB upgrade, and I hit some snags as reported here:

thread: wanted to erase it, but I think I killed it

I would like to ask the community if it makes sense to modify two aspects of the current drive upgrade document that Tony Fabris maintains. The problem is, I don't know enough of the history here to know if the recommendations are sensible.

• The upgrade document currently points people to www.empeg.com for the .upgrade image files. But, the car2-builder.upgrade image there failed to work for me, and also failed to work for the poster in this thread. There are LBA48 images at rtr.ca/bigdisk which are mentioned by the drive upgrade document, and these worked flawlessly for me. (Note, I have two 30GB drives so I shouldn't have needed these.)
  
  Is there any reason we wouldn't want to recommend the LBA48 images as the primarily recommended upgrade images? How many folks going forward will be upgrading to small disks, now that you can buy 250GB drives for $99 shipped? And even if they did have a small drive, what's the harm of using the LBA48 image?
• The upgrade document says if you get a "drives already built" message from the drive builder, that you need to press Enter to get things going. However, this did not work for me, or for the other poster mentioned above. A look at the 'init' script shows that if it detects fids/ on the drive, the script simply aborts to a bash prompt. Hitting Enter simply invokes another prompt. The linked post above describes the solution - remount the drive read/write, delete the fids/, and reboot the player, and the drive builder will happily go on to make the filesystems.
  
  I don't know if hitting Enter is the right behavior in any other upgrade image, but I know it's required for the LBA48 builder. Does anyone have experience to share here on whether the upgrade document should be modified with the fids/ deletion steps?

- Chris

I think that Mark's builder images should be the de-facto way to build a new empeg, no matter how big the disk is. To be honest, if I get new disks for my empegs, I'll be using it, even though I know how to do it by hand.

If we could, it'd be great to get them hosted on empeg.com or riocar.org, but I don't know how likely that would be.

Mark, if you're reading...

Do the bigdisk builder images behave differently than the factory builder images with regard to the situation when the disk is already built?

Specifically, I was told that the factory builder images, if there was already data on the drive, required a press of the ENTER key on the serial connection to get them to continue to partition/format/stresstest the drives. Did this behavior change with your bigdisk images?

Chrispitude is reporting that this behavior didn't work as expected when he tried it. At the point he was supposed to press Enter, it was already dropped to a shell prompt so it did nothing.




Rob V, or whoever currently controls the empeg.com web site:

Is the builder 2.0 upgrade file on the web site corrupt? If so, it should be fixed please.

Who is in charge of the files at empeg.com?

Or: can we just get www.empeg.com to redirect to riocar.org? It'll get a bit more love there. As long as the software is brought across, obviously.

The MX will have to stay the same, though, 'cos I think it's still being used.

That functionality doesn't seem to work with the factory images, and I just dropped it completely from my own at some point.

So, if the drive is "already built", one must manually delete the fids directories before the builder will overwrite it. I'll "fix" that someday, but not today.

Cheers

Okay, so the Drive Upgrade Guide, as Chrispitude has been trying to tell me all along, has been in error for a very long time and I need to fix it.

Working on it...

Okay, I think it's fixed. Anyone who's interested in fact-checking it, go for it.

Thank you Tony!

By the way, I was able to simply restart the builder by doing an



after issuing those commands. This basically restarted the upgrader image. This is the same command I use to restart my home linux box. I would also imagine you could simply power-cycle the unit with the existing builder image installed. I don't think you actually have to re-install the image.

Oh, and I like your style on the modifications for the various images! ("On second thought...")

- Chris

Hi,

I reviewed the FAQ and have the following recommendations:

1) In the 6th paragraph... There are also other tricks you can do that can increase those limitations, discussed in detail here.

You might want to add the reserve cache information for the larger file systems (like 2 250GB drives). Like the the post by Mark Lord and Peter (Which they should provide a concise paragraph for the FAQ ....

Like this with two 250GB drives installed ?

I think it is very likely that there is simply insufficient RAM in the Empeg to hold the necessary data structures (kernel and player) for filesystems of that size.

You may be able to work around it, by shifting more memory away from the player software, using the ReserveCache=nn flag in the player's config.ini file:


[Startup]
;; Tell the player to leave about 1MB of RAM for other uses:
ReserveCache=15


Oddly, the Empeg FAQ entry for this suggests that each chunk is reported to be a bit larger than 32kBytes -- we've known for a few years now that each chunk is actually 64kBytes.


The original releases did use 32K chunks, but I can't remember when we changed it to be 64K... possibly it was as long ago as between v1 and v2, which would indeed mean that most people on the BBS are probably using 64K now.


I think the problem is very likely that there is simply not enough utility RAM for the kernel to keep track of the filesystem data structures for two very large filesystems as you have there.

Increasing the ReserveCache= setting should help a lot -- every count of 16 represents a megabyte, but then that memory is taken away from the player's own cache (and thus the root of the problem: player s/w trying to maintain a duplicate of the kernel's own cache, thus taking near 2X the RAM in doing so).

So, try perhaps ReserveCache=48 -- I don't know how much RAM it really needs, but that ought to quiet things down a fair bit. If it does, then installing the RAM upgrade kit will help a lot as a longer term solution.


I'm not sure what you mean by this. There certainly isn't enough RAM in the player for the kernel's block cache to get to anything like the same size as the player's chunk cache. The player uses mlock, so it'd be more accurate to say that the player "successfully overrides" the kernel's cache, rather than "tries to maintain a duplicate". The extra memory used (as compared to, say, using O_DIRECT; mmap was buggy in ARM kernels that old) is the size of a single chunk: 64K. Which the kernel then evicts from (what it finds to be) its very meagre block cache when then next 64K is requested.



2) The paragraph you tell them when to apply power and instantly use the Serial port to see it format the drive.... You might indicate when the format occurs, it will "pump the partition" and when it completes it, that's when the real reboot happens that you want to watch it create the inodes. If you do this before then it will conflict and not let you do it.

3) Just after the paragraph where tell them how to remove the FIDS and the builder completes and runs the disk stress test .... You might mention that the latest Big Disk Builder v10 does not perform a Disk Stress test. It reports on the Empeg Display that the build is completed.

It has been a while since I partitioned drives, so this is from memory of when I did a few of 250 GB drives.

Thanks,

Ross

Thanks, Ross. I made a couple of edits, but not all of them, perhaps I'll come back later and figure out a way to make the reservecache stuff clearer and more understandable. Thanks for your help!