On 07/13/2012 03:22 PM, Ian Perkins wrote:
I essentially followed Solid Run's wiki, which links to a binary build
of rc8. There were some issues (likely due to their usage of Ubuntu,
versus Red Sleeve's RH conventions), but I found workarounds, which I
will document!
If you get the tar balls from the ZoL web site, they are already set up
to build RPMs.
Glad to hear you got it working. ARM support was added to ZoL in the
most recent release (0.6.0-rc9). I find ZFS is quite handy on ARM
machines for 2 reasons:
In my case, I got a type 10 card, in the hope that wear management will
be a little better.
That doesn't really follow at all. In my experience the class ratings
are pretty close to meaningless. Take a look here:
http://www.altechnative.net/2012/01/25/flash-module-benchmark-collection-sd-cards-cf-cards-usb-sticks/
particular the link at the bottom to the test result tables, and
especially the table at the bottom.
The only two cards worth bothering with are the Integral Endurance (SLC,
19 random write IOPS) and SanDisk Extreme Pro 95MB/s (actually manages
to match the performance of a 7200rpm disk on random writes with 133
random write IOPS).
I have not yet found any other SD cards that are worth bothering with,
and that includes the likes of "Class 16" Pretec which scores quite well
on sequential writes but appallingly badly on random writes.
I put the zfs pool on two 250 GB sata drives that I
had lying around, so I may very well run into a memory issue in actually
trying to use the pool. I should note that the esata chipset on the
Cubox does do port multiplication, so the unit see both drives.
Sweet, so you actually have a SATA port multiplier, running both drives
off the same SATA port on the CuBox? Awesome! :)
1) Most of them run from SD cards or other cheap/inadequate flash
media that seems to expire very quickly when used for the rootfs.
ZFS helps because it tries to write data out in large blocks, up to
128KB, where possible. It is also copy-on-write so it tends to not
overwrite data in place, which makes it slightly less bad when it
comes to wear leveling. It also helps with the performance on media
that is reasonably passable at large-ish sequential writes but
utterly useless when doing small random writes.
2) Some of the cheap media has wear management that is so poor that
some parts can expire before others (if they behave correctly, they
should just block further writes and turn the media read-only in
order to preserve the data). Most of the time if this goes wrong,
you tend to get silent corruption. ZFS keeps data checksups so at
least you can see when this starts happening - hopefully before
something important gets corrupted.
The only downside is that supposedly ZoL still has issues on 32-bit
platforms due to memory requirements. Having said that, this only
seems to be an issue with large file systems. I don't see it being a
problem with file systems the size of SD cards. Still, if you run
into any issues, please do post about them on the ZoL list so that
they can be looked into and fixed.
Well, I did want to do this (in part) to become more adept with Linux
:) I'll put RPMs right behind uboot on my list.
Hehe, so you jumped straight into the deep end with ARM.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
