Amahi embedded...

[rjwaldren]

Is anyone using Amahi with an embedded like install...
By embedded I mean running on USB or CF card. I relalize the install options are based on a standard Fedora HDD install. My intent is to reserve SATA ports for storage drives.

So far I've just been playing in a VM, while my NAS is running embedded FreeNAS from a CF. I would like to move to Amahi, but I foresee problems doing it from CF or USB stick. I suppose if I use RAID1/5 I could mount /var to the array and relieve alot of writes to the flash device. But if I go with greyhole won't I need to dedicate space on my storage drives for the landing zone?

I'm interested in how other may have this set up

[liam]

I'm interested in this too, for a USB boot drive, and two SATA drives for data. I need to know the minimum size USB drive required. And can I set up the swap file on one of the SATA drives?

Also, what is the minimum Fedora custom instal for Amahi, i.e. what components can I leave out?

I am hoping to instal on a 4Gb eUSB drive

Any advice much appreciated

[rjwaldren]

Liam,

Using the F12 based expressCD with no Amahi applications installed the OS drive was ~1.3GB. I've upgraded that expressCD install to F14 again with no Amahi applications and it wieghs about 1.9GB. So you could probably install ExpressCD to a 2GB drive if you wanted to but when you start adding features you'd really want at least 4GB.

For the by the book install from F12 and F14 DVD's it was in the range of ~5.5GB if IIRC - So a fully install should fit nicely on a 8GB flash drive - provided I can sensibly relocate /var and swap to a mechanical drive without requiring additional drives outside of my storage drives to do so. I would prefer that my storage drives were single partitions which only contained my data - I don't think that's possible using Amahi without an additional HDD dedicated to OS. Then it requires custom modifications to the mount point's and deviations which would be likely to break during upgrades.

The other issue is that neither is really is intended to run on a flash device and amahi makes alot of use of /var - writes are major killer of consumer grade flash drives.

[cpg]

You could turn off access updates in /var if it's in flash and that will help a lot, since most of the time these files will be in memory and very few writes will take place. You could move the logs somewhere else too (say with a link). That will help too!

Would love to hear about your experiences!

[rjwaldren]

I certainly update, I've been in a VM up to now - Unfortunately I updated VBox to v4.0.2 last night and completely broke NAT and Bridged networking for all of my VM's...Right after I found a VPN config that is functional from work and right before you went and dropped the v6 beta on us!

For at least Amahi, it's time to test on real hardware anyway. I'll pop it on a jumpdrive and test it on what was my freenas test server. My big questions are how much of /var needs to move and I want to study greyhole with real data.

[liam]

You could turn off access updates in /var if it's in flash and that will help a lot, since most of the time these files will be in memory and very few writes will take place. You could move the logs somewhere else too (say with a link).

Thanks cpg, please can you point me to a useful how-to which takes me through the steps?

it requires custom modifications to the mount point's and deviations which would be likely to break during upgrades

That's a worry for me

neither is really is intended to run on a flash device and amahi makes alot of use of /var - writes are major killer of consumer grade flash drives

I have industrial grade SLC flash drives, one is a 4Gb eUSB, the other a 16Gb compact flash.

Is it Fedora or Amahi that is particularly unsuitable for flash drives? Does this mean SSD drives are not ideal too?

I'll have a look later but would appreciate any advice on best practice with flash boot drives with Fedora/Amahi, I'm sure I'm not the only one considering this.

many thanks

[rjwaldren]

The issue is writes... Consumer grade flash is usually cheaper memory and prone to fail quickly under heavy write conditions, to be fair it's gotten better over time, but the devices are really intend for storage-not active OS's. The work around is to move the more active parts of the OS onto more write friendly storage. In the case of linux /var, /tmp, /home are usually where the heaviest writes occur so in the case of embedded systems these are usually relocated to virtual file systems (ie ramdisk) or to a HDD.

I wouldn't expect your SLC devices to be a problem, but the space may become and issue depending on how you configure or use your system.

As far as moving /var to a separate device. It's basically just mounting your target partition to a temporary location and moving the contents of your current /var to the partition, you'd be best to do this in single user mode. Then edit fstab to mount your target partition to /var. They best way is to do it during a clean fedora install, choose manual partitions and create a custom mount for /var right from the beginning.

[radioz]

It is important to point out that for an Amahi system, critical parts of /var need to be preserved across power cycles, so for us moving all of /var to a tempfile system would not work (since the tempfile system would be lost on power off).

Using flash is an interesting way of reducing system size and power requirements.

Thanks.

[liam]

Thanks for the advice, I'll try find time to explore further, but in the meantime I think I'll stick with my current instal on SATA.

Using flash is an interesting way of reducing system size and power requirements.

There are also significant advantages in terms of speed, and noise.

I'm coming over to Linux from Windows XP, so am a complete Linux newbie. There's a lot of experience now with tweaking XP for SSD drives. My understanding from the mini-itx community was that Linux was the OS of choice in the embedded world, with systems booting from compact flash, USB as well as SSD. So I am surprised that there appear to be issues with Fedora/Amahi.

Look forward to hearing of other people's experiences

[rjwaldren]

Unfortunately I had some vbox breakage with the latest version this week. My intent was to trace through the boot process to determine what needs to be available and when in relation to the mount scripts. This should determine what parts of /var can be moved off of the os drive. Agree a TMPFS is not suitable without significant changes in the way amahi is designed to work.

Liam, I think flash drive and SSD are two different things at least in common usage. IMO, most would consider "flash drives" to be jump/thumb drives for portable storage - where reads vastly outweigh the writes. The type of memory used typically is rated for minimal write cycles and use as an OS drive without taking precautions to minimize the writes eats them up pretty fast.

Common usage of the term SSD, is for devices that are designed with a type type/grade of flash memory intended to replace a mechanical harddrive and capable of much higher write cycles. You devices probably fall more into this category.

When someone asks, "can I install this on a usb flash drive?" they typically mean something like a Kingston Datatraveler. The answer is yes but it might not last long. They answer is simply yes if you are using a intel x25.

Some *nix distros have "embedded" variants that work around these issues by relocating high volume writes to tmpfs or another physical drive. The official Fedora distro which acts as the base for amahi is designed for the data to be persistent. By contrast a distro like freeNAS embedded stores it's configuration and dynamic data to a data base that rebuilds the structures into a ram based FS during boot - The drive is used as readonly with only configuration changes written to the database. Alot of work goes into determining what needs to be persistent and what can be vapor. To be honest, I'm doubting it's worth pursuing on Fedora/Amahi for a usb/cf as will require a separate persistent storage location - might as well just install the whole thing there and be done with it.