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