Hi Mike, Thanks for the info, this was just the information I was looking for. I have successfully flashed my slug with SlugOS(BE) 5.3-beta, run turnup init ,Message 1 of 17 , Feb 22, 2011View SourceHi Mike,
Thanks for the info, this was just the information I was looking for.
I have successfully flashed my slug with SlugOS(BE) 5.3-beta, run "turnup
init", formatted the disk (in the enclosure using Ubuntu live CD) and it is
recognized by the slug
So I am ready to establish a better partitioning scheme and then progress
towards my "happier slug"
On 22/02/2011 12:55 am, Mike Westerhof wrote:
> On 2/21/2011 4:59 AM, Ian White wrote:
>> 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
> 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?? ;-)]
> -Mike (mwester)
>> Sorry for the long-ish post and thanks in advance for any advice/tips
>> 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.
I have re-flashed my formerly unslung slug with SlugOS/BE and set up my desired partitioning structure But when I came to install the various optwareMessage 1 of 17 , Mar 10, 2011View SourceI have re-flashed my formerly "unslung" slug with SlugOS/BE and set up my
desired partitioning structure
But when I came to install the various optware packages including coreutils,
rsync, samba, python etc.
I found that there were no packages for librsync and rdiff-backup
Are these (librsync and rdiff-backup) available for SlugOS/BE
or should I go for a Debian-based slug firmware/Debian install to obtain
access to Debian's larger package collection?