On 2/21/2011 4:59 AM, Ian White wrote:
[snip]
> So the advice needed is as follows:
>
> 1) Will SlugOS cope with a 2TB drive?
Yes. You might, however, need the latest development version of SlugOS
if the chipset in your enclosure is not supported by the older kernel in
SlugOS 5.3.
> 2) What sort of partitioning scheme would work best?
> (I am inclined to partition the drive into at least 2 x 1TB
> partitions, just so the checks are quicker and only 1/2 of the data is
> "lost" if a partition becomes corrupt)
You'll need a rootfs, and that should be separate from the data. And
breaking up such large partitions is a good idea. So that would imply
at least three partitions - a small one (a GB or two is more than
adequate) for the rootfs, and then the two data partitions.
> 3) I'm betting that I also need some swap space because SlugOS will not
> cope with these sized partitions using ram alone?
> Any recommended size for this swap space? (Like do I need say 1GB
> swap per 1TB of partition to be "fsck"'d)
You'll need swap -- but usually its sized based on the RAM in the device
(using the rule-of-thumb of 1x or 2x the amount of RAM), and then one
sees if your workload will fit into that. In your case, there's no real
way to know:
a) For fsck, there are pathological cases of corruption that will run
almost ANY system out of swap, so there's no guaranteed amount you can
configure that will allow you to repair all types of damage. Moreover,
once you get into the 4x-swap-to-memory range, your performance is
probably such that you'll never finish the fsck anyway.
b) For rsync, the amount of memory will depend on the size of the
filelist, since it builds that data-structure in-memory. So there is an
upper limit based on what you are presenting to rsync -- you'll have to
present it with the worst-case workload, and measure it's virtual memory
consumption and that will tell you how much virtual memory you need (and
make your swap space slightly to double that figure, depending on what
you do about the dreaded OOM Killer).
You'll have to sort what to do about that most evil of all Linux kernel
creations, the Out-Of-Memory Killer. This ugly monster's job is to
prevent the system from crashing by detecting a situation that might
result in a shortfall of virtual memory and terminating a process that
would avoid that shortfall. It's rather like throwing passengers out of
the airplane when low on fuel, in order to save the remaining
passengers. [http://lwn.net/Articles/104185/]
You can either create a swap partition, or just use a swap file; it
really makes no difference for the NSLU2 (any performance difference due
to filesystem overhead is buried by the slowness of USB in the first place).
Also, you might like to tweak the "volatiles" settings (deep down
beneath the /etc directory) -- you'll be wanting to move as much stuff
out of the tmpfs filesystems as you can. In fact, since those
filesystems come right out of the RAM, you might like to replace them
entirely with real filesystems, thus making sure that nothing writing a
temp file to /tmp or /var/tmp will end up consuming precious memory.
Here's a starting point for configuring your new, happier slug (after
all, ALL slugs are happier when running SlugOS [<-- our new marketing
slogan -- what do you thing?? ;-)]
http://www.nslu2-linux.org/wiki/SlugOS/InstallandTurnupABasicSlugOSSystem
-Mike (mwester)
> Sorry for the long-ish post and thanks in advance for any advice/tips
>
> TIA
> Ian White
>
> P.S. The other NAS devices are a Qnap and 2 Linkstations, all with
> "root" access, but the Slug was my first NAS, so I think it deserves
> some continued effort on my part.
No comments:
Post a Comment