Secondary store

Hi,

I'm trying to replace the box that does most of my basic
network services, here:  DNS, BOOTP, DHCP, Font server,
NTP, TFTP, etc.

All have reasonably light footprints (I think!).  But,
all have been written (NetBSD) assuming gobs of memory
available!

As the little box I am repurposing has a fixed (small)
amount of RAM, I am nervous about building a "noswap"
kernel -- the idea of one (or more) of the services
failing and, thus, being unavailable (perhaps indefinitely
depending on what else may be consuming core) doesn't leave
me happy (getting a physical console on the box is tedious
due to its out-of-the way location, etc.)

In the past, I've crammed small 2.5" drives into boxes like
this to handle the boot image *and* swap needs.  "No brainer".

But, this box is much smaller.  I thought, perhaps, a 1.8"
drive?  But, unsure how those hold up to 24/7/365 use (I
have only encountered them in things like Zunes, etc.).

Also, they seem to use a flex circuit/ZIF connector so I'd
have to cobble a 44-pin adapter (probably also voltage reg).

Any other suggestions I could try?  I had thought of a CF
card but imagine that would wear out in short order.  I also
have some small PCMCIA (hard) disk drives that I thought might
fit the bill...

Thx,
--don

On 22/08/14 22:34, Don Y wrote:
> Hi,
>
> I'm trying to replace the box that does most of my basic
> network services, here:  DNS, BOOTP, DHCP, Font server,
> NTP, TFTP, etc.
>
> All have reasonably light footprints (I think!).  But,
> all have been written (NetBSD) assuming gobs of memory
> available!
>
> As the little box I am repurposing has a fixed (small)
> amount of RAM, I am nervous about building a "noswap"
> kernel -- the idea of one (or more) of the services
> failing and, thus, being unavailable (perhaps indefinitely
> depending on what else may be consuming core) doesn't leave
> me happy (getting a physical console on the box is tedious
> due to its out-of-the way location, etc.)
>
> In the past, I've crammed small 2.5" drives into boxes like
> this to handle the boot image *and* swap needs.  "No brainer".
>
> But, this box is much smaller.  I thought, perhaps, a 1.8"
> drive?  But, unsure how those hold up to 24/7/365 use (I
> have only encountered them in things like Zunes, etc.).
>
> Also, they seem to use a flex circuit/ZIF connector so I'd
> have to cobble a 44-pin adapter (probably also voltage reg).
>
> Any other suggestions I could try?  I had thought of a CF
> card but imagine that would wear out in short order.  I also
> have some small PCMCIA (hard) disk drives that I thought might
> fit the bill...
>
> Thx,
> --don

Hi Don,

If you want to get help here you're going to have to give more useful 
information.  For starters:

Are you building this yourself?

Is it a one-off, or are you producing them?  What is your budget?

Is the hardware fixed?

How much disk space do you want?  How many disks?  What about raid, etc.?

How much memory are you talking about here?  GB's of memory cost pennies 
as long as you can use fairly modern types.  But all of these services 
can run fine on a machine with perhaps 128 MB ram.

Why are you thinking of NetBSD?  It is not a bad OS, but it is rarely 
used - unless you have special reason, go for a mainstream Linux distro.

A CF card will never wear out if you have set things up appropriately. 
In particular, put /tmp, /var/tmp, /var/log and perhaps other /var areas 
on tmpfs rather than on the disk, and make sure you have your mounts 
with noatime.  Pretty much everything that is needed to run these 
services will be loaded near the start, and stay in cache, so there will 
be little reading of the disk, and almost nothing will be written to it 
if your logs are in ram.

Hi David,

On 8/23/2014 8:20 AM, David Brown wrote:
> On 22/08/14 22:34, Don Y wrote:

>> I'm trying to replace the box that does most of my basic
>> network services, here: DNS, BOOTP, DHCP, Font server,
>> NTP, TFTP, etc.

>> As the little box I am repurposing has a fixed (small)
>> amount of RAM, I am nervous about building a "noswap"
>> kernel -- the idea of one (or more) of the services
>> failing and, thus, being unavailable (perhaps indefinitely
>> depending on what else may be consuming core) doesn't leave
>> me happy (getting a physical console on the box is tedious
>> due to its out-of-the way location, etc.)

>> But, this box is much smaller. I thought, perhaps, a 1.8"
>> drive? But, unsure how those hold up to 24/7/365 use (I
>> have only encountered them in things like Zunes, etc.).

>> Any other suggestions I could try? I had thought of a CF
>> card but imagine that would wear out in short order. I also
>> have some small PCMCIA (hard) disk drives that I thought might
>> fit the bill...

> If you want to get help here you're going to have to give more useful
> information. For starters:
>
> Are you building this yourself?

No.  It's a COTS device:  "the little box I am repurposing"

> Is it a one-off, or are you producing them? What is your budget?

See above.  This is just an interim measure until I can redesign
and reimplement all of the services in a manner more consistent
with the overall design of the system.

> Is the hardware fixed?

Yes.  Well, I could always try to find something *else* COTS that
is small, already "packaged", low power, etc.  But, I don't want
to turn this into a "real project"... just hack together something
quick.

> How much disk space do you want? How many disks? What about raid, etc.?

The current COTS box that has been performing these tasks for the
past several years has a ~12G disk (2.5") in it.  Of that, about
5G is in use (OS, fonts, etc.) with 4G of swap.  No need for RAID.
Box is small enough that I just dd(1) an image of the disk over the
network to a file server as "backup".

> How much memory are you talking about here? GB's of memory cost pennies
> as long as you can use fairly modern types. But all of these services
> can run fine on a machine with perhaps 128 MB ram.

I can't add to the existing memory -- it's all soldered down
("appliance").  Nominally 128MB but you always lose ~8MB to the
video system.

> Why are you thinking of NetBSD? It is not a bad OS, but it is rarely
> used - unless you have special reason, go for a mainstream Linux distro.

Uptime of > 1000 days says NetBSD has done fine by me, so far -- why
change?  :>

(Also, I don't build systems/devices around GPL'd code -- I don't want
to pass any encumberances on to others choosing to replicate said
systems/devices)

> A CF card will never wear out if you have set things up appropriately.
> In particular, put /tmp, /var/tmp, /var/log and perhaps other /var areas
> on tmpfs rather than on the disk, and make sure you have your mounts
> with noatime. Pretty much everything that is needed to run these
> services will be loaded near the start, and stay in cache, so there will
> be little reading of the disk, and almost nothing will be written to it
> if your logs are in ram.

I can keep *most* (deliberate) writes off the medium easy enough (as
above).  E.g., with so little "disk to spare" in the existing
implementation, I can't waste space on verbose logging, deep log files,
etc.

OTOH, it's not realistic to put a limit on how deep the print or mail
spools will be; how many telnet, http, font, etc. sessions to support;
etc.

Swapctl(8) shows minimal swap incursion -- about 40MB.  But, that's
just "current conditions" -- no idea what the *peak* usage may have
been -- nor under what conditions.

As a first step, I will remove services that aren't essential for
this box (e.g., nessusd) and sort out a more "practical" (though,
undoubtedly, less *convenient*) way of handling them going forward.
I'll probably have to kiss goodbye to running most X clients off the
box in favor of a lighterweight interface (e.g., each xfontsel(1)
instance is several MB; nessus(1) is about 10MB/instance; etc.).

I.e., there is value to having cheap/"no power" volatile storage
on hand (hence the appeal of physically small disks).  In a "final"
solution, I can move much of the R/O data off the system to reduce
the *dual* appeal of the disk as "program store + swap".  But,
that's a fair bit of work.

Which leaves me back at the 1.8" disk drives...

On 23/08/14 20:17, Don Y wrote:
> Hi David,
>
> On 8/23/2014 8:20 AM, David Brown wrote:
>> On 22/08/14 22:34, Don Y wrote:
>
>>> I'm trying to replace the box that does most of my basic
>>> network services, here: DNS, BOOTP, DHCP, Font server,
>>> NTP, TFTP, etc.
>
>>> As the little box I am repurposing has a fixed (small)
>>> amount of RAM, I am nervous about building a "noswap"
>>> kernel -- the idea of one (or more) of the services
>>> failing and, thus, being unavailable (perhaps indefinitely
>>> depending on what else may be consuming core) doesn't leave
>>> me happy (getting a physical console on the box is tedious
>>> due to its out-of-the way location, etc.)
>
>>> But, this box is much smaller. I thought, perhaps, a 1.8"
>>> drive? But, unsure how those hold up to 24/7/365 use (I
>>> have only encountered them in things like Zunes, etc.).
>
>>> Any other suggestions I could try? I had thought of a CF
>>> card but imagine that would wear out in short order. I also
>>> have some small PCMCIA (hard) disk drives that I thought might
>>> fit the bill...
>
>> If you want to get help here you're going to have to give more useful
>> information. For starters:
>>
>> Are you building this yourself?
>
> No.  It's a COTS device:  "the little box I am repurposing"
>
>> Is it a one-off, or are you producing them? What is your budget?
>
> See above.  This is just an interim measure until I can redesign
> and reimplement all of the services in a manner more consistent
> with the overall design of the system.

I still don't see anything about your numbers.  How many systems are you 
talking about?  It is going to have to be a /very/ large number with 
prices under $50 for the complete system (with disk) for it to be worth 
the effort here.  Otherwise you could be using something like this (from 
a 30 second google search):

<http://www.linux.com/learn/tutorials/735815-cubieboard-arm-a8-cpu-with-sata-for-under-50>

Plenty of processing power, 1 GB ram, 4 GB flash (which is masses for 
your OS and setup) and USB/Sata/Micro-SD for additional storage.

>
>> Is the hardware fixed?
>
> Yes.  Well, I could always try to find something *else* COTS that
> is small, already "packaged", low power, etc.  But, I don't want
> to turn this into a "real project"... just hack together something
> quick.
>
>> How much disk space do you want? How many disks? What about raid, etc.?
>
> The current COTS box that has been performing these tasks for the
> past several years has a ~12G disk (2.5") in it.  Of that, about
> 5G is in use (OS, fonts, etc.) with 4G of swap.  No need for RAID.
> Box is small enough that I just dd(1) an image of the disk over the
> network to a file server as "backup".
>
>> How much memory are you talking about here? GB's of memory cost pennies
>> as long as you can use fairly modern types. But all of these services
>> can run fine on a machine with perhaps 128 MB ram.
>
> I can't add to the existing memory -- it's all soldered down
> ("appliance").  Nominally 128MB but you always lose ~8MB to the
> video system.
>
>> Why are you thinking of NetBSD? It is not a bad OS, but it is rarely
>> used - unless you have special reason, go for a mainstream Linux distro.
>
> Uptime of > 1000 days says NetBSD has done fine by me, so far -- why
> change?  :>

That makes sense, as long as it works.  NetBSD is going to be a 
limitation for hardware and software - but if you are happy within those 
limits, then there is no need to change.  And if you are familiar with 
the low levels of NetBSD, you would need to re-learn some of it on a 
change to Linux.

>
> (Also, I don't build systems/devices around GPL'd code -- I don't want
> to pass any encumberances on to others choosing to replicate said
> systems/devices)

That is almost certainly a misunderstanding in many ways, but that's a 
question for a different thread.

>
>> A CF card will never wear out if you have set things up appropriately.
>> In particular, put /tmp, /var/tmp, /var/log and perhaps other /var areas
>> on tmpfs rather than on the disk, and make sure you have your mounts
>> with noatime. Pretty much everything that is needed to run these
>> services will be loaded near the start, and stay in cache, so there will
>> be little reading of the disk, and almost nothing will be written to it
>> if your logs are in ram.
>
> I can keep *most* (deliberate) writes off the medium easy enough (as
> above).  E.g., with so little "disk to spare" in the existing
> implementation, I can't waste space on verbose logging, deep log files,
> etc.
>
> OTOH, it's not realistic to put a limit on how deep the print or mail
> spools will be; how many telnet, http, font, etc. sessions to support;
> etc.

You can run a system with minimal ram, /or/ you can run it with minimal 
writes to disk.  You can't have both - at least, not if you have a a 
fair amount of temporary information (such as spools).

>
> Swapctl(8) shows minimal swap incursion -- about 40MB.  But, that's
> just "current conditions" -- no idea what the *peak* usage may have
> been -- nor under what conditions.
>
> As a first step, I will remove services that aren't essential for
> this box (e.g., nessusd) and sort out a more "practical" (though,
> undoubtedly, less *convenient*) way of handling them going forward.
> I'll probably have to kiss goodbye to running most X clients off the
> box in favor of a lighterweight interface (e.g., each xfontsel(1)
> instance is several MB; nessus(1) is about 10MB/instance; etc.).
>
> I.e., there is value to having cheap/"no power" volatile storage
> on hand (hence the appeal of physically small disks).  In a "final"
> solution, I can move much of the R/O data off the system to reduce
> the *dual* appeal of the disk as "program store + swap".  But,
> that's a fair bit of work.
>
> Which leaves me back at the 1.8" disk drives...

Your storage sizes are so small that SD-Card or USB memory sticks are 
likely to be cheaper than a 1.8" disk - as well as being lower power and 
physically smaller.

Hi David,

On 8/24/2014 4:55 AM, David Brown wrote:
> On 23/08/14 20:17, Don Y wrote:
>> On 8/23/2014 8:20 AM, David Brown wrote:
>>> On 22/08/14 22:34, Don Y wrote:
>>
>>>> I'm trying to replace the box that does most of my basic
>>>> network services, here: DNS, BOOTP, DHCP, Font server,
>>>> NTP, TFTP, etc.
>>
>>>> As the little box I am repurposing has a fixed (small)
>>>> amount of RAM, I am nervous about building a "noswap"
>>>> kernel -- the idea of one (or more) of the services
>>>> failing and, thus, being unavailable (perhaps indefinitely
>>>> depending on what else may be consuming core) doesn't leave
>>>> me happy (getting a physical console on the box is tedious
>>>> due to its out-of-the way location, etc.)
>>
>>>> But, this box is much smaller. I thought, perhaps, a 1.8"
>>>> drive? But, unsure how those hold up to 24/7/365 use (I
>>>> have only encountered them in things like Zunes, etc.).
>>
>>>> Any other suggestions I could try? I had thought of a CF
>>>> card but imagine that would wear out in short order. I also
>>>> have some small PCMCIA (hard) disk drives that I thought might
>>>> fit the bill...
>>
>>> If you want to get help here you're going to have to give more useful
>>> information. For starters:
>>>
>>> Are you building this yourself?
>>
>> No. It's a COTS device: "the little box I am repurposing"
>>
>>> Is it a one-off, or are you producing them? What is your budget?
>>
>> See above. This is just an interim measure until I can redesign
>> and reimplement all of the services in a manner more consistent
>> with the overall design of the system.
>
> I still don't see anything about your numbers. How many systems are you

"THE little box I am repurposing".  I.e., I am currently interested
in exactly *one* -- to replace the *one* existing box (with the 3yr
uptime).  As I said before, I will be rewriting each of these services
to better fit with the rest of the "system" I've been building so
that's where my real effort lies.  The redesigned form will have to
run with *greatly* reduced hardware resources (e.g., approaching that
of an SoC)

> talking about? It is going to have to be a /very/ large number with
> prices under $50 for the complete system (with disk) for it to be worth
> the effort here. Otherwise you could be using something like this (from
> a 30 second google search):
>
> <http://www.linux.com/learn/tutorials/735815-cubieboard-arm-a8-cpu-with-sata-for-under-50>
>
> Plenty of processing power, 1 GB ram, 4 GB flash (which is masses for
> your OS and setup) and USB/Sata/Micro-SD for additional storage.

The Flash available wouldn't fit my current needs.  The 1G of RAM
*may* eliminate the need for a swap device (assuming my current box
never uses more than ~800M of swap).

I have lots of "boards" that I can use.  What I want is a *box* so
that I'm not spending time fitting a bare board to a case, making it
"look pretty", etc.  When it's done, I want to be able to make another
(or, tell someone else how to make another) easily.

>> I can't add to the existing memory -- it's all soldered down
>> ("appliance"). Nominally 128MB but you always lose ~8MB to the
>> video system.
>>
>>> Why are you thinking of NetBSD? It is not a bad OS, but it is rarely
>>> used - unless you have special reason, go for a mainstream Linux distro.
>>
>> Uptime of > 1000 days says NetBSD has done fine by me, so far -- why
>> change? :>
>
> That makes sense, as long as it works. NetBSD is going to be a
> limitation for hardware and software - but if you are happy within those
> limits, then there is no need to change. And if you are familiar with
> the low levels of NetBSD, you would need to re-learn some of it on a
> change to Linux.

I've never found a bit of COTS hardware on which I couldn't readily get
a NetBSD system up and running.  And, all of the "software" that *has*
to run on it has already *been* running on a similar box.

>> (Also, I don't build systems/devices around GPL'd code -- I don't want
>> to pass any encumberances on to others choosing to replicate said
>> systems/devices)
>
> That is almost certainly a misunderstanding in many ways, but that's a
> question for a different thread.

I want a system derived from my sources to be effectively
indistinguishable in a "licensee's" business model from any other
product designed internally.  No need to feed improvements back;
no EXPECTATION to receive improvements that others may introduce;
no need to supply folks with the materials from which *you* started
the effort; no need to even tell people the basis for your product;
etc.  I.e., just like the case where the design was done entirely
"in house" -- EXCEPT that you realize others may also have benefited
from the same "head start" as you (i.e., *you* have to innovate from
that potentially common starting point)

>>> A CF card will never wear out if you have set things up appropriately.
>>> In particular, put /tmp, /var/tmp, /var/log and perhaps other /var areas
>>> on tmpfs rather than on the disk, and make sure you have your mounts
>>> with noatime. Pretty much everything that is needed to run these
>>> services will be loaded near the start, and stay in cache, so there will
>>> be little reading of the disk, and almost nothing will be written to it
>>> if your logs are in ram.
>>
>> I can keep *most* (deliberate) writes off the medium easy enough (as
>> above). E.g., with so little "disk to spare" in the existing
>> implementation, I can't waste space on verbose logging, deep log files,
>> etc.
>>
>> OTOH, it's not realistic to put a limit on how deep the print or mail
>> spools will be; how many telnet, http, font, etc. sessions to support;
>> etc.
>
> You can run a system with minimal ram, /or/ you can run it with minimal
> writes to disk. You can't have both - at least, not if you have a a fair
> amount of temporary information (such as spools).

Yes.  So you need "secondary store" of some sort.  Even if you want to
call it "slow RAM".

>> Swapctl(8) shows minimal swap incursion -- about 40MB. But, that's
>> just "current conditions" -- no idea what the *peak* usage may have
>> been -- nor under what conditions.
>>
>> As a first step, I will remove services that aren't essential for
>> this box (e.g., nessusd) and sort out a more "practical" (though,
>> undoubtedly, less *convenient*) way of handling them going forward.
>> I'll probably have to kiss goodbye to running most X clients off the
>> box in favor of a lighterweight interface (e.g., each xfontsel(1)
>> instance is several MB; nessus(1) is about 10MB/instance; etc.).
>>
>> I.e., there is value to having cheap/"no power" volatile storage
>> on hand (hence the appeal of physically small disks). In a "final"
>> solution, I can move much of the R/O data off the system to reduce
>> the *dual* appeal of the disk as "program store + swap". But,
>> that's a fair bit of work.
>>
>> Which leaves me back at the 1.8" disk drives...
>
> Your storage sizes are so small that SD-Card or USB memory sticks are
> likely to be cheaper than a 1.8" disk - as well as being lower power and
> physically smaller.

But they will suffer from the same endurance issue that any
NON-volatile semiconductor memory exhibits.  AFAICT, there are no
SD-card or USB "RAM" devices (and, a USB hard disk just adds
another "box" to the mix).

On 24/08/14 19:01, Don Y wrote:
> Hi David,
>
> On 8/24/2014 4:55 AM, David Brown wrote:
>> On 23/08/14 20:17, Don Y wrote:
>>> On 8/23/2014 8:20 AM, David Brown wrote:
>>>> On 22/08/14 22:34, Don Y wrote:
>>>
>>>>> I'm trying to replace the box that does most of my basic
>>>>> network services, here: DNS, BOOTP, DHCP, Font server,
>>>>> NTP, TFTP, etc.
>>>
>>>>> As the little box I am repurposing has a fixed (small)
>>>>> amount of RAM, I am nervous about building a "noswap"
>>>>> kernel -- the idea of one (or more) of the services
>>>>> failing and, thus, being unavailable (perhaps indefinitely
>>>>> depending on what else may be consuming core) doesn't leave
>>>>> me happy (getting a physical console on the box is tedious
>>>>> due to its out-of-the way location, etc.)
>>>
>>>>> But, this box is much smaller. I thought, perhaps, a 1.8"
>>>>> drive? But, unsure how those hold up to 24/7/365 use (I
>>>>> have only encountered them in things like Zunes, etc.).
>>>
>>>>> Any other suggestions I could try? I had thought of a CF
>>>>> card but imagine that would wear out in short order. I also
>>>>> have some small PCMCIA (hard) disk drives that I thought might
>>>>> fit the bill...
>>>
>>>> If you want to get help here you're going to have to give more useful
>>>> information. For starters:
>>>>
>>>> Are you building this yourself?
>>>
>>> No. It's a COTS device: "the little box I am repurposing"
>>>
>>>> Is it a one-off, or are you producing them? What is your budget?
>>>
>>> See above. This is just an interim measure until I can redesign
>>> and reimplement all of the services in a manner more consistent
>>> with the overall design of the system.
>>
>> I still don't see anything about your numbers. How many systems are you
>
> "THE little box I am repurposing".  I.e., I am currently interested
> in exactly *one* -- to replace the *one* existing box (with the 3yr
> uptime).  As I said before, I will be rewriting each of these services
> to better fit with the rest of the "system" I've been building so
> that's where my real effort lies.  The redesigned form will have to
> run with *greatly* reduced hardware resources (e.g., approaching that
> of an SoC)

OK.  I am just trying to understand why you are trying to get such a 
small system.  I don't expect you to throw money at something more 
extravagant than necessary, and I can understand wanting a physically 
small system, but it surprises me that you are aiming so small and cheap 
despite the extra effort involved.

>
>> talking about? It is going to have to be a /very/ large number with
>> prices under $50 for the complete system (with disk) for it to be worth
>> the effort here. Otherwise you could be using something like this (from
>> a 30 second google search):
>>
>> <http://www.linux.com/learn/tutorials/735815-cubieboard-arm-a8-cpu-with-sata-for-under-50>
>>
>>
>> Plenty of processing power, 1 GB ram, 4 GB flash (which is masses for
>> your OS and setup) and USB/Sata/Micro-SD for additional storage.
>
> The Flash available wouldn't fit my current needs.  The 1G of RAM
> *may* eliminate the need for a swap device (assuming my current box
> never uses more than ~800M of swap).

The 4GB will handle the OS and server programs - you would need to add 
storage for your data.

>
> I have lots of "boards" that I can use.  What I want is a *box* so
> that I'm not spending time fitting a bare board to a case, making it
> "look pretty", etc.  When it's done, I want to be able to make another
> (or, tell someone else how to make another) easily.

 From the picture, it looked like this board had a sort of a box (I have 
never used these boards).  A micro SD card will fit in fine.

But I am getting pretty confused here about your requirements.  Maybe I 
am being a little dense.  As far as I understand it, you said above that 
you wanted a single test/development system for now, with a plan to 
build a tiny replacement later.  So why does it matter if you need to 
put everything in an old shoebox for now?  Alternatively, why not spend 
slightly more dollars and a lot less hours and pulled-out hair by buying 
a ready-made box with a half-decent board?

>
>>> I can't add to the existing memory -- it's all soldered down
>>> ("appliance"). Nominally 128MB but you always lose ~8MB to the
>>> video system.
>>>
>>>> Why are you thinking of NetBSD? It is not a bad OS, but it is rarely
>>>> used - unless you have special reason, go for a mainstream Linux
>>>> distro.
>>>
>>> Uptime of > 1000 days says NetBSD has done fine by me, so far -- why
>>> change? :>
>>
>> That makes sense, as long as it works. NetBSD is going to be a
>> limitation for hardware and software - but if you are happy within those
>> limits, then there is no need to change. And if you are familiar with
>> the low levels of NetBSD, you would need to re-learn some of it on a
>> change to Linux.
>
> I've never found a bit of COTS hardware on which I couldn't readily get
> a NetBSD system up and running.  And, all of the "software" that *has*
> to run on it has already *been* running on a similar box.
>

OK.  I haven't used NetBSD, so I'll take your word for it.

>>> (Also, I don't build systems/devices around GPL'd code -- I don't want
>>> to pass any encumberances on to others choosing to replicate said
>>> systems/devices)
>>
>> That is almost certainly a misunderstanding in many ways, but that's a
>> question for a different thread.
>
> I want a system derived from my sources to be effectively
> indistinguishable in a "licensee's" business model from any other
> product designed internally.  No need to feed improvements back;
> no EXPECTATION to receive improvements that others may introduce;
> no need to supply folks with the materials from which *you* started
> the effort; no need to even tell people the basis for your product;
> etc.  I.e., just like the case where the design was done entirely
> "in house" -- EXCEPT that you realize others may also have benefited
> from the same "head start" as you (i.e., *you* have to innovate from
> that potentially common starting point)
>
>>>> A CF card will never wear out if you have set things up appropriately.
>>>> In particular, put /tmp, /var/tmp, /var/log and perhaps other /var
>>>> areas
>>>> on tmpfs rather than on the disk, and make sure you have your mounts
>>>> with noatime. Pretty much everything that is needed to run these
>>>> services will be loaded near the start, and stay in cache, so there
>>>> will
>>>> be little reading of the disk, and almost nothing will be written to it
>>>> if your logs are in ram.
>>>
>>> I can keep *most* (deliberate) writes off the medium easy enough (as
>>> above). E.g., with so little "disk to spare" in the existing
>>> implementation, I can't waste space on verbose logging, deep log files,
>>> etc.
>>>
>>> OTOH, it's not realistic to put a limit on how deep the print or mail
>>> spools will be; how many telnet, http, font, etc. sessions to support;
>>> etc.
>>
>> You can run a system with minimal ram, /or/ you can run it with minimal
>> writes to disk. You can't have both - at least, not if you have a a fair
>> amount of temporary information (such as spools).
>
> Yes.  So you need "secondary store" of some sort.  Even if you want to
> call it "slow RAM".

Yes - you need "real ram" or "slow ram".

>
>>> Swapctl(8) shows minimal swap incursion -- about 40MB. But, that's
>>> just "current conditions" -- no idea what the *peak* usage may have
>>> been -- nor under what conditions.
>>>
>>> As a first step, I will remove services that aren't essential for
>>> this box (e.g., nessusd) and sort out a more "practical" (though,
>>> undoubtedly, less *convenient*) way of handling them going forward.
>>> I'll probably have to kiss goodbye to running most X clients off the
>>> box in favor of a lighterweight interface (e.g., each xfontsel(1)
>>> instance is several MB; nessus(1) is about 10MB/instance; etc.).
>>>
>>> I.e., there is value to having cheap/"no power" volatile storage
>>> on hand (hence the appeal of physically small disks). In a "final"
>>> solution, I can move much of the R/O data off the system to reduce
>>> the *dual* appeal of the disk as "program store + swap". But,
>>> that's a fair bit of work.
>>>
>>> Which leaves me back at the 1.8" disk drives...
>>
>> Your storage sizes are so small that SD-Card or USB memory sticks are
>> likely to be cheaper than a 1.8" disk - as well as being lower power and
>> physically smaller.
>
> But they will suffer from the same endurance issue that any
> NON-volatile semiconductor memory exhibits.  AFAICT, there are no
> SD-card or USB "RAM" devices (and, a USB hard disk just adds
> another "box" to the mix).

Endurance is a question of how you use the devices - in particular, how 
much you write to them.  If you avoid unnecessary writes with noatime 
mounts (or the NetBSD equivalent) and putting logs and other temporary 
files in a tmpfs (or NetBSD equivalent), then they will last a very long 
time.  Any 1.8" disk you can buy now will be SSD, not an HD, so you are 
going to be using solid state disk anyway.  It's true that SSD's usually 
have more endurance than USB memory sticks or SD cards, but personally I 
would not worry about using a reasonable quality SD card for such purposes.

Hi David,

On 8/24/2014 2:34 PM, David Brown wrote:

[much elided]

>>>>>> But, this box is much smaller. I thought, perhaps, a 1.8"
>>>>>> drive? But, unsure how those hold up to 24/7/365 use (I
>>>>>> have only encountered them in things like Zunes, etc.).
>>>>
>>>>>> Any other suggestions I could try? I had thought of a CF
>>>>>> card but imagine that would wear out in short order. I also
>>>>>> have some small PCMCIA (hard) disk drives that I thought might
>>>>>> fit the bill...
>>>>
>>>>> If you want to get help here you're going to have to give more useful
>>>>> information. For starters:
>>>>>
>>>>> Are you building this yourself?
>>>>
>>>> No. It's a COTS device: "the little box I am repurposing"
>>>>
>>>>> Is it a one-off, or are you producing them? What is your budget?
>>>>
>>>> See above. This is just an interim measure until I can redesign
>>>> and reimplement all of the services in a manner more consistent
>>>> with the overall design of the system.
>>>
>>> I still don't see anything about your numbers. How many systems are you
>>
>> "THE little box I am repurposing". I.e., I am currently interested
>> in exactly *one* -- to replace the *one* existing box (with the 3yr
>> uptime). As I said before, I will be rewriting each of these services
>> to better fit with the rest of the "system" I've been building so
>> that's where my real effort lies. The redesigned form will have to
>> run with *greatly* reduced hardware resources (e.g., approaching that
>> of an SoC)
>
> OK. I am just trying to understand why you are trying to get such a
> small system. I don't expect you to throw money at something more
> extravagant than necessary, and I can understand wanting a physically
> small system, but it surprises me that you are aiming so small and cheap
> despite the extra effort involved.

Lots of different (though related) issues, here (we've drifted from
the original question).

I have a little box that has been satisfactorily providing these
services for many years.

I have been in a "downsizing" mode for the past year -- trying to
shed equipment, etc. as I focus on my future efforts.  In digging
through my "goodies", I've come across several "boxes" (small
systems) that are not currently being used.  I.e., good candidates
to *discard*.

One such box is "attractively packaged", smaller, lower power
consumption, and more capable (MIPS) than the box that has been
providing these services.  It has an internal 44 pin "disk" connector
(intended for a DoC device) much like the existing "service box".
I.e., instead of discarding this nice little box, why not pull the
2.5" drive from the existing box (software is already configured and
running) and move it to the *new* box -- discarding the OLD one in
its place?!  (OK, maybe I have to tweak the kernel but that's a few
hours, tops)

Ah, 2.5" drive won't *fit* in this tiny little box!  Either need to go
with a CF card *or* a 1.8" disk.  *OR*, turn this into a "project"
(in which case, why not just keep what I *have*?).  A 1.8->2.5 adapter
is relatively easy to come by.  So, a 1.8" disk just requires that
adapter and a few minutes to build a file system on the disk and
copy everything from the OLD disk!

OTOH, if 1.8" disks aren't very reliable (or performant) -- keep in mind
my experiences with them are limited to personal media players -- then
this would be a problem waiting to manifest "shortly" (when the disk
eventually bites the shed)

The final issue (long term) deals with how those services will be
eventually implemented -- just "decomposed" processes migrating
among available processor nodes as resources become available,
shift, etc.  (instead of a single hardware device with a specific
dedicated functionality)  So, the resources required to implement
each service need to be minimized so it can shoehorn into other
boxes alongside their "normal apps" without impacting their
defined responsibilities.

>> I have lots of "boards" that I can use. What I want is a *box* so
>> that I'm not spending time fitting a bare board to a case, making it
>> "look pretty", etc. When it's done, I want to be able to make another
>> (or, tell someone else how to make another) easily.
>
> From the picture, it looked like this board had a sort of a box (I have
> never used these boards). A micro SD card will fit in fine.
>
> But I am getting pretty confused here about your requirements. Maybe I
> am being a little dense. As far as I understand it, you said above that
> you wanted a single test/development system for now, with a plan to
> build a tiny replacement later. So why does it matter if you need to put
> everything in an old shoebox for now? Alternatively, why not spend
> slightly more dollars and a lot less hours and pulled-out hair by buying
> a ready-made box with a half-decent board?

Shoebox is icky.  This has to be reliable enough to meet my needs
without worrying about being jostled, something spilled on it, etc.
And, if something goes wrong, I need to be able to get it back
up and running without making a "project" out of that effort.

E.g., the existing box hides under a dresser.  I have a 9" microkeyboard
plugged into it and a video cable secured to the video jack on its rear.
So, if it is not working, I can drag out a monitor and see what sort
of messages are "displayed" there -- as well as interact with it if
there is something that needs to be "fixed" from a "console".  Then,
unplug the monitor (I have a little 7" monitor that I use for these
sorts of things) and toss the keyboard back under the dresser...

As this "new" box looks a lot like a PC (keyboard, mouse, video,
printer, serial, audio, USB, network ports), the same approach should
work equally well.  (no CD/DVD media but neither does the old box...
nor is it needed!)

>>>> Swapctl(8) shows minimal swap incursion -- about 40MB. But, that's
>>>> just "current conditions" -- no idea what the *peak* usage may have
>>>> been -- nor under what conditions.
>>>>
>>>> As a first step, I will remove services that aren't essential for
>>>> this box (e.g., nessusd) and sort out a more "practical" (though,
>>>> undoubtedly, less *convenient*) way of handling them going forward.
>>>> I'll probably have to kiss goodbye to running most X clients off the
>>>> box in favor of a lighterweight interface (e.g., each xfontsel(1)
>>>> instance is several MB; nessus(1) is about 10MB/instance; etc.).
>>>>
>>>> I.e., there is value to having cheap/"no power" volatile storage
>>>> on hand (hence the appeal of physically small disks). In a "final"
>>>> solution, I can move much of the R/O data off the system to reduce
>>>> the *dual* appeal of the disk as "program store + swap". But,
>>>> that's a fair bit of work.
>>>>
>>>> Which leaves me back at the 1.8" disk drives...
>>>
>>> Your storage sizes are so small that SD-Card or USB memory sticks are
>>> likely to be cheaper than a 1.8" disk - as well as being lower power and
>>> physically smaller.
>>
>> But they will suffer from the same endurance issue that any
>> NON-volatile semiconductor memory exhibits. AFAICT, there are no
>> SD-card or USB "RAM" devices (and, a USB hard disk just adds
>> another "box" to the mix).
>
> Endurance is a question of how you use the devices - in particular, how
> much you write to them. If you avoid unnecessary writes with noatime
> mounts (or the NetBSD equivalent) and putting logs and other temporary
> files in a tmpfs (or NetBSD equivalent), then they will last a very long
> time. Any 1.8" disk you can buy now will be SSD, not an HD, so you are
> going to be using solid state disk anyway. It's true that SSD's usually
> have more endurance than USB memory sticks or SD cards, but personally I
> would not worry about using a reasonable quality SD card for such purposes.

Hmmm... I didn't think that was the case.  I thought you could still buy
rotating media in a 1.8" form factor (though I have no experience with
how robust and performant it would be)

On Sun, 24 Aug 2014 16:39:01 -0700, Don Y <this@is.not.me.com> wrote:

>Hi David,
>
>On 8/24/2014 2:34 PM, David Brown wrote:
>
>[much elided]
>
>>>>>>> But, this box is much smaller. I thought, perhaps, a 1.8"
>>>>>>> drive? But, unsure how those hold up to 24/7/365 use (I
>>>>>>> have only encountered them in things like Zunes, etc.).
>>>>>
>>>>>>> Any other suggestions I could try? I had thought of a CF
>>>>>>> card but imagine that would wear out in short order. I also
>>>>>>> have some small PCMCIA (hard) disk drives that I thought might
>>>>>>> fit the bill...
>>>>>
>>>>>> If you want to get help here you're going to have to give more useful
>>>>>> information. For starters:
>>>>>>
>>>>>> Are you building this yourself?
>>>>>
>>>>> No. It's a COTS device: "the little box I am repurposing"
>>>>>
>>>>>> Is it a one-off, or are you producing them? What is your budget?
>>>>>
>>>>> See above. This is just an interim measure until I can redesign
>>>>> and reimplement all of the services in a manner more consistent
>>>>> with the overall design of the system.
>>>>
>>>> I still don't see anything about your numbers. How many systems are you
>>>
>>> "THE little box I am repurposing". I.e., I am currently interested
>>> in exactly *one* -- to replace the *one* existing box (with the 3yr
>>> uptime). As I said before, I will be rewriting each of these services
>>> to better fit with the rest of the "system" I've been building so
>>> that's where my real effort lies. The redesigned form will have to
>>> run with *greatly* reduced hardware resources (e.g., approaching that
>>> of an SoC)
>>
>> OK. I am just trying to understand why you are trying to get such a
>> small system. I don't expect you to throw money at something more
>> extravagant than necessary, and I can understand wanting a physically
>> small system, but it surprises me that you are aiming so small and cheap
>> despite the extra effort involved.
>
>Lots of different (though related) issues, here (we've drifted from
>the original question).
>
>I have a little box that has been satisfactorily providing these
>services for many years.
>
>I have been in a "downsizing" mode for the past year -- trying to
>shed equipment, etc. as I focus on my future efforts.  In digging
>through my "goodies", I've come across several "boxes" (small
>systems) that are not currently being used.  I.e., good candidates
>to *discard*.
>
>One such box is "attractively packaged", smaller, lower power
>consumption, and more capable (MIPS) than the box that has been
>providing these services.  It has an internal 44 pin "disk" connector
>(intended for a DoC device) much like the existing "service box".
>I.e., instead of discarding this nice little box, why not pull the
>2.5" drive from the existing box (software is already configured and
>running) and move it to the *new* box -- discarding the OLD one in
>its place?!  (OK, maybe I have to tweak the kernel but that's a few
>hours, tops)
>
>Ah, 2.5" drive won't *fit* in this tiny little box!  Either need to go
>with a CF card *or* a 1.8" disk.  *OR*, turn this into a "project"
>(in which case, why not just keep what I *have*?).  A 1.8->2.5 adapter
>is relatively easy to come by.  So, a 1.8" disk just requires that
>adapter and a few minutes to build a file system on the disk and
>copy everything from the OLD disk!
>
>OTOH, if 1.8" disks aren't very reliable (or performant) -- keep in mind
>my experiences with them are limited to personal media players -- then
>this would be a problem waiting to manifest "shortly" (when the disk
>eventually bites the shed)
>
>The final issue (long term) deals with how those services will be
>eventually implemented -- just "decomposed" processes migrating
>among available processor nodes as resources become available,
>shift, etc.  (instead of a single hardware device with a specific
>dedicated functionality)  So, the resources required to implement
>each service need to be minimized so it can shoehorn into other
>boxes alongside their "normal apps" without impacting their
>defined responsibilities.
>
>>> I have lots of "boards" that I can use. What I want is a *box* so
>>> that I'm not spending time fitting a bare board to a case, making it
>>> "look pretty", etc. When it's done, I want to be able to make another
>>> (or, tell someone else how to make another) easily.
>>
>> From the picture, it looked like this board had a sort of a box (I have
>> never used these boards). A micro SD card will fit in fine.
>>
>> But I am getting pretty confused here about your requirements. Maybe I
>> am being a little dense. As far as I understand it, you said above that
>> you wanted a single test/development system for now, with a plan to
>> build a tiny replacement later. So why does it matter if you need to put
>> everything in an old shoebox for now? Alternatively, why not spend
>> slightly more dollars and a lot less hours and pulled-out hair by buying
>> a ready-made box with a half-decent board?
>
>Shoebox is icky.  This has to be reliable enough to meet my needs
>without worrying about being jostled, something spilled on it, etc.
>And, if something goes wrong, I need to be able to get it back
>up and running without making a "project" out of that effort.
>
>E.g., the existing box hides under a dresser.  I have a 9" microkeyboard
>plugged into it and a video cable secured to the video jack on its rear.
>So, if it is not working, I can drag out a monitor and see what sort
>of messages are "displayed" there -- as well as interact with it if
>there is something that needs to be "fixed" from a "console".  Then,
>unplug the monitor (I have a little 7" monitor that I use for these
>sorts of things) and toss the keyboard back under the dresser...
>
>As this "new" box looks a lot like a PC (keyboard, mouse, video,
>printer, serial, audio, USB, network ports), the same approach should
>work equally well.  (no CD/DVD media but neither does the old box...
>nor is it needed!)
>
>>>>> Swapctl(8) shows minimal swap incursion -- about 40MB. But, that's
>>>>> just "current conditions" -- no idea what the *peak* usage may have
>>>>> been -- nor under what conditions.
>>>>>
>>>>> As a first step, I will remove services that aren't essential for
>>>>> this box (e.g., nessusd) and sort out a more "practical" (though,
>>>>> undoubtedly, less *convenient*) way of handling them going forward.
>>>>> I'll probably have to kiss goodbye to running most X clients off the
>>>>> box in favor of a lighterweight interface (e.g., each xfontsel(1)
>>>>> instance is several MB; nessus(1) is about 10MB/instance; etc.).
>>>>>
>>>>> I.e., there is value to having cheap/"no power" volatile storage
>>>>> on hand (hence the appeal of physically small disks). In a "final"
>>>>> solution, I can move much of the R/O data off the system to reduce
>>>>> the *dual* appeal of the disk as "program store + swap". But,
>>>>> that's a fair bit of work.
>>>>>
>>>>> Which leaves me back at the 1.8" disk drives...
>>>>
>>>> Your storage sizes are so small that SD-Card or USB memory sticks are
>>>> likely to be cheaper than a 1.8" disk - as well as being lower power and
>>>> physically smaller.
>>>
>>> But they will suffer from the same endurance issue that any
>>> NON-volatile semiconductor memory exhibits. AFAICT, there are no
>>> SD-card or USB "RAM" devices (and, a USB hard disk just adds
>>> another "box" to the mix).
>>
>> Endurance is a question of how you use the devices - in particular, how
>> much you write to them. If you avoid unnecessary writes with noatime
>> mounts (or the NetBSD equivalent) and putting logs and other temporary
>> files in a tmpfs (or NetBSD equivalent), then they will last a very long
>> time. Any 1.8" disk you can buy now will be SSD, not an HD, so you are
>> going to be using solid state disk anyway. It's true that SSD's usually
>> have more endurance than USB memory sticks or SD cards, but personally I
>> would not worry about using a reasonable quality SD card for such purposes.
>
>Hmmm... I didn't think that was the case.  I thought you could still buy
>rotating media in a 1.8" form factor (though I have no experience with
>how robust and performant it would be)


Of course you omitted the crucial bit of information, namely that you
needed a PATA drive or parallel SCSI drive (I suspect the MIPS box may
have a SCSI drive).  Certainly you can still get 1.8" PATA rotating
drives, but they're mostly old stock.  I think you'll be hard pressed
to find 1.8" parallel SCSI drives, though.  I don't even know if any
such ever existed.

If you have a SATA interface (or SAS), SSD remains the obvious choice.
Even a cheapo Intel 530 80GB SSD is rated for 20GB/day for five years.
And the system you're describing should do nowhere near that amount of
paging.  If you want to pay for an enterprise drive, you can get an
800GB DC S3500 with 250GB/day for five years (with those the write
rating is proportional to the drive size, and the S3500s are available
in 80-800GB sizes).

Hi Robert,

On 8/24/2014 9:53 PM, Robert Wessel wrote:
> On Sun, 24 Aug 2014 16:39:01 -0700, Don Y<this@is.not.me.com>  wrote:

[much elided]

>>>>>>>> But, this box is much smaller. I thought, perhaps, a 1.8"
>>>>>>>> drive? But, unsure how those hold up to 24/7/365 use (I
>>>>>>>> have only encountered them in things like Zunes, etc.).

---------------------------------------^^^^^^^^^^^^^^^^^

>>>>>>>> Any other suggestions I could try? I had thought of a CF
>>>>>>>> card but imagine that would wear out in short order. I also
>>>>>>>> have some small PCMCIA (hard) disk drives that I thought might
>>>>>>>> fit the bill...

>> One such box is "attractively packaged", smaller, lower power
>> consumption, and more capable (MIPS) than the box that has been

Ugh!  Overloaded acronym?

----------------------------------^^^^ (Million Instructs Per Second)

>> providing these services.  It has an internal 44 pin "disk" connector
>> (intended for a DoC device) much like the existing "service box".
>> I.e., instead of discarding this nice little box, why not pull the
>> 2.5" drive from the existing box (software is already configured and
>> running) and move it to the *new* box -- discarding the OLD one in
>> its place?!  (OK, maybe I have to tweak the kernel but that's a few
>> hours, tops)

>> Ah, 2.5" drive won't *fit* in this tiny little box!  Either need to go
>> with a CF card *or* a 1.8" disk.  *OR*, turn this into a "project"
>> (in which case, why not just keep what I *have*?).  A 1.8->2.5 adapter
>> is relatively easy to come by.  So, a 1.8" disk just requires that
>> adapter and a few minutes to build a file system on the disk and
>> copy everything from the OLD disk!
>>
>> OTOH, if 1.8" disks aren't very reliable (or performant) -- keep in mind
>> my experiences with them are limited to personal media players -- then
>> this would be a problem waiting to manifest "shortly" (when the disk
>> eventually bites the shed)

>> As this "new" box looks a lot like a PC (keyboard, mouse, video,

---------------------^^^^^^^^^^^^^^^^^^^^^ (not a MIPS/RISC based box)

>> printer, serial, audio, USB, network ports), the same approach should
>> work equally well.  (no CD/DVD media but neither does the old box...
>> nor is it needed!)

> Of course you omitted the crucial bit of information, namely that you
> needed a PATA drive or parallel SCSI drive (I suspect the MIPS box may
> have a SCSI drive).

 From myinitial post:

     "But, this box is much smaller.  I thought, perhaps, a 1.8"
     drive?  But, unsure how those hold up to 24/7/365 use (I
     have only encountered them in things like Zunes, etc.)."

[If you've never disassembled a Zune, they use 1.8" drives with Toshiba
flex circuit interface]

     "Also, they seem to use a flex circuit/ZIF connector so I'd
     have to cobble a 44-pin adapter (probably also voltage reg)."

[PATA is 44 pin in the 2.5" size]

> Certainly you can still get 1.8" PATA rotating
> drives, but they're mostly old stock.  I think you'll be hard pressed
> to find 1.8" parallel SCSI drives, though.  I don't even know if any
> such ever existed.

I've only (rarely) seen 2.5" SCSI drives.  E.g., my Sun Voyager uses
such.

Note the 12G 2.5" PATA drive in the existing "old" box wouldn't qualify
for "new" in the last decade!  :>

On 8/24/2014 4:39 PM, Don Y wrote:

> E.g., the existing box hides under a dresser. I have a 9" microkeyboard
> plugged into it and a video cable secured to the video jack on its rear.
> So, if it is not working, I can drag out a monitor and see what sort
> of messages are "displayed" there -- as well as interact with it if
> there is something that needs to be "fixed" from a "console". Then,
> unplug the monitor (I have a little 7" monitor that I use for these
> sorts of things) and toss the keyboard back under the dresser...
>
> As this "new" box looks a lot like a PC (keyboard, mouse, video,
> printer, serial, audio, USB, network ports), the same approach should
> work equally well. (no CD/DVD media but neither does the old box...
> nor is it needed!)

Well, my relative unease wrt the 1.8" drives (I'd hate to dump the
exiting WORKING box in favor of the new box on the assumption that
the 1.8" drive would be comparable in terms of performance and
durability) led me to more aggressively examining the "new" box
with an eye towards shoehorning a 2.5" drive into the (smaller)
space.

[Something about Necessity's mother comes to mind...]

Turns out that I could move the dinky speaker (1 inch?) and that
would give me an extra 1/4" to just barely cram a 2.5" drive in
without worrying about it leaning on a heatsink or shorting
something unintentionally (no way to *secure* the drive in place...
but, there was no way to secure a 1.8" drive, either!).

Having done that, I moved the 12G drive from the old box into the
new and -- pleasant surprise!  :>

Ethernet controller and IDE controller (perhaps "extended features"
thereof -- as the system *is* talking to the disk) weren't present
in the kernel I had built for the old system (why include drivers
in a kernel image on a resource starved box if they aren't needed?).

So, added two lines from the GENERIC kernel configuration file to the
file for the old system (I *should* have elided the old IDE and
Ethernet drivers!  Grrrr... guess I will have to build a second pass
at the final kernel), "make config" followed by the appropriate
"make install" and all is now well!

Perhaps I'll replace the 12G drive with another (I think the smallest
remaining drive is 30G) rather than risk it crapping out on me, now!

And, turns out the old system was probably ready to fail -- several
bulging caps...  :<