Secondary store

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.

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

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.

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.

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".

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.

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)

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...

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):

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.

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.

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

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).

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.

"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)

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'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.

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)

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

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).

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.

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

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?

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

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

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.

[much elided]

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.

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!)

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).

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

Ugh! Overloaded acronym?

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

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

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]

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! :>

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... :<

For about 7 years my router was a Netgear WGT634U. That was the usual consumer specs: 200MHz 32-bit MIPS CPU, 16MB flash 32MB RAM. Only it wasn't running the Netgear firmware, it was running full Debian/mips from a USB stick (1GB or 2GB, being reasonably big back then).

Debian in 32MB is fairly constrained, especially when running various servers as I was, which meant it was hammering the USB stick all day every day using it as swap. I replaced the USB stick once or twice as a precaution, but never had an issue with wearout. The old sticks went into my junk drawer, where they still are and still work.

So if you need a 'swap' device, use a USB flash stick. Don't use SD, CF or (worst) micro SD - there isn't enough space for buffer memory so performance is worse than USB. Just replace it every few years and you should be fine.

Theo

Did you ever look to see what peak swap usage was?

How speedy is "thrashing" via USB? I.e., will I lose all my MIPS gains to a USB bottleneck? (the newer box -- now running with a 2.5" drive cobbled inside -- is ~112MB/800MHz)

I may try that! There are provisions for two internal USB "sticks". I had originally thought of using a USB wireless adapter and trying a USB "R/O" image for the OS/executables -- leaving the disk in place to gather metrics about how it uses swap.

But, I could skip the wireless adapter and add a second thumb drive to act as "swap device" -- so the system is never at risk (if the system image wasn't accessible, booting to recover/repair would be problematic!)

And, if this works, replace the disk with a CF card (for the OS and executables), a thumb drive for swap and then add the wireless adapter back in...

That's an interesting first-hand account - I would not have liked to use a USB flash stick or other small card for swap. (Real SSD's, especially reasonable quality devices, are fine for swap.)

It's an odd choice to run a full Debian on such a system - typically distros like OpenWRT are more popular on such hardware. Even 7 years ago it had packages for many useful servers, and you would get the server software itself in the 16 MB flash - leaving the USB for data and, if necessary, swap.

I think I set it up with 32MB DRAM and 256MB swap. I think typical usage was ~128MB of swap was used, though of course lots of things are paged out until they get used (eg servers idling until somebody connects to their socket). I didn't measure swap bandwidth/traffic.

It's not quick, but I had a 200MHz router so I didn't expect it to be quick anyway. What helped a lot was to buy a flash stick with decent random write performance: at the time such were marked Vista ReadyBoost compatible. These days they tend to emphasise bulk speeds, but if you can find one with a CrystalDiskMark benchmark (Amazon listings are good for this) it helps. For example, something like this, though the drive mentioned is a bit expensive today:

I don't know if today buying 'USB3' sticks is helpful in getting the faster ones - I must do some proper tests at some point.

Theo

This was 2005. OpenWRT wasn't as advanced at that point - it particular there weren't as many packages, and the setup was substantially different. Plus 16MB flash isn't enough to fit much in - I ran a full Asterisk server on it for instance (fine apart from not enough CPU to do transcoding). I really dislike busybox and I don't want to be interacting with it on a daily basis (it's got better now).

The router (and its flash) was still functional when I retired it 2 years ago: at short notice I needed a SSH-accessible Linux router for an inaccessible hostile remote location, so I reflashed it with modern OpenWRT and last I heard it was working fine.

Theo

tros like OpenWRT are more popular on such hardware. Even 7 years ago it h ad packages for many useful servers, and you would get the server software itself in the 16 MB flash - leaving the USB for data and, if necessary, swa p.

there weren't as many packages, and the setup was substantially different. Plus 16MB flash isn't enough to fit much in - I ran a full Asterisk server on it for instance (fine apart from not enough CPU to do transcoding). I r eally dislike busybox and I don't want to be interacting with it on a daily basis (it's got better now).

ago: at short notice I needed a SSH-accessible Linux router for an inacces sible hostile remote location, so I reflashed it with modern OpenWRT and la st I heard it was working fine.

Why deal with old stuffs, when newer hardwares are dirt cheap.

My GSM/Wifi router runs on a 16G microSD via USB. With 1G system memory on 1.6GHz dual core Atom, speed is not a problem. With at least 8G log space, it should outlast me as well.

Should I feel guilty about wasting resources? But it draws not much more p ower than COTS router, perhaps 5W average. And the netbook cost me less th an $50, becasuse of a cracked LCD screen.

BTW, there is a 250G hard drive i am not using, in order to save power. It 's always powered down.

I also have another Window 7 laptop and Linux Mint laptop. I got tired of dual booting, so just use two laptops at the same time.

Why deal with NEW stuff when *newer* stuff will be even CHEAPER? :>

What's your suggestion? Discard the old? "Ah, it's Jan 1 -- time for a new cell phone!"

One of the places I volunteered at accepted donated items that they converted to cash (by refurbishing/reselling/recycling) and then using the cash to fund "aid" operations. We processed 3.5 tons every week. And, most people were either unaware of our existence or unwilling to be bothered with hauling their kit *to* us!

Recycling is horribly inefficient -- *if* you actually have folks actively participating and service agencies that can use all of the recycled material!

Plastic is trash. Folks won't even TRY to recycle it -- no "return" there!

Sheet metal (e.g., computer cases) are a penny or two per pound (depending on whether they are "clean" or still have bits of plastic, etc. attached that must be processed/removed/discarded.

A nice copper (or aluminum) heatsink is golden! "Motherboards" are maybe a couple of dollars per pound.

I.e., take your brand new computer and recycle it -- and you will probably get about $10 out of it!

Contrast that with what it costs to purchase -- even "manufacturer's COST". The difference represents the inefficiency in the recycling process BEST CASE (as often raw materials are cheaper to *extract* than *recover*!)

From a technical viewpoint, chances are you'll have more documentation for older kit than newer items -- especially as most manufacturers don't publish anything technically useful (so, your kit needs to be "available" long enough for someone to become interested in exploring it in detail and publishing their own observations).

There is also personal satisfaction at having *done* something (no matter how trivial) instead of just "buying a solution". And, the leveraging the knowledge gained to produce other solutions with different constraints (e.g., when I have to migrate these services to even fewer resources).

These 5 to 6 years old netbooks are useless otherwise, but they are better than your 10+ years stuff. If i don't use them, they will be trashed anywa y. First, they are made unusable with Vista, but they are great for Linux router. The 10" screen and resolutions are too small for real work.

In the case of my Gateway, the external case was so weak that plenty of the m got cracked LCD. So, you can pick them up cheap for around $50.

new cell phone!"

The better of two evils: recycle newer trash first.

Actually, for me, those netbooks are the ideal size and weight to be able to drop into a backpack and pull out again on the train.

They are small enough to not take up a major part of a 15 litre backpack and they are light enough not to be really noticable while walking around a city (although I wouldn't carry one on a long distance day walk. :-))

I run Scientific Linux 5.x on mine (an Acer Aspire 1).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

I've wanted to hack a small laptop to make a KMM out of it. Instead, I've had to settle for a 7" monitor and a 9" keyboard kept together in a little sack for those uses. (of course, wouldn't help *you* as you want a "real machine" on your travels)

I keep an old Sony laptop (back when CD, floppy, etc. were *external* devices) for those times when I want something small, email, etc. Has the added advantage that if it got lost/grew legs I wouldn't miss it! :>