Re: [Xen-users] [XCP] Install to Flash Media

["Nick Couchman" <Nick.Couchman@xxxxxxxxx>]

On Fri, 2012-02-10 at 16:06 -0800, Scott Mewett wrote:
> What file system are you going to use?

Since I'm using XCP, I don't think I have choice in the matter.  XCP
uses ext3 as the default FS.

> 
> With flash media you will eventually wear out your device, wearing out 
> specific blocks and then using up spare blocks which will then cause the 
> device to go offline or the filesystem to go readonly. While each block can 
> be written millions of times, all it takes is a the same block to be 
> repeatedly written to. There are parts of the filesystem that are like that. 
> Such as a journal.
> 
> You can go with extending the commit interval but that is dangerous. Maybe 
> not so much if you consider that you're not writing important data. Just boot 
> files etc. But still your not going to like that if the writes were needless. 
>  So some extra work on your part can help identify and weed out those 
> processes.
> 
> I'd recommend a ext2, and also mount with noatime to reduce the unnecessary 
> writes.

Thanks for the hints.  I've mounted with the noatime and noload
parameters.  The noload disabled loading of the journal; however, I'm
not sure whether it actually disables the journal functionality or not.
I may need to remount with ext2 instead of ext3, which should be the
same as disabling journaling.  However, since this is just the dom0
management interface and the hypervisor, and I'm logging to a remote
host, I don't think it'll be too bad.

> 
> Beware of lock or stat files that get touched regularly. Those too create 
> lots of writes unnecessarily. You could use a really small ramfs for those 
> dirs. This is great for a file or directory that has state information which 
> won't matter after a reboot.
> 
> You can do some tests watching for io to the disks to see what processes are 
> writing to what parts.
> echo 1 > /proc/sys/vm/block_dump
> Use dmesg or redirect with klog to a file to see the process name, id, inode, 
> filename, and device.
> On a journaled file system like ext3, you'll see your write, and then a few 
> seconds later you'll see the journal commit the changes.
> Notice that the same inodes get written to over and over. Sort and word count 
> those to see how many times in a minute or hour and you'll see the heavily 
> used blocks.
> 
> Doing this upfront can give you many years of reliable usage. Without it, you 
> could easily wear out your device in a year.
> 
> Also, flash blocks or pages are not the same as your file system blocks. It's 
> not a 1 to 1 relationship. So 1 512byte FS block, could be sharing a page 
> with other blocks. Writes to 2 separate FS blocks could affect the same flash 
> page.

I'll definitely look into all of these things, as well.

> 
> There are also flash file systems (i.e. jffs2 and a number of others) that 
> are supported by the linux kernel. Most distributions don't support those by 
> default, so you may have to recompile your kernel to include it. They are 
> more common on embedded systems. But they are out there and they do the extra 
> work for you of leveling the where on on the flash device.

Yeah, it'd be nice if the XCP or XenServer products had an option to
install to flash media - many of the newer servers still include
flash-based devices as options for loading hypervisors and the like.

-Nick



--------
This e-mail may contain confidential and privileged material for the sole use 
of the intended recipient.  If this email is not intended for you, or you are 
not responsible for the delivery of this message to the intended recipient, 
please note that this message may contain SEAKR Engineering (SEAKR) 
Privileged/Proprietary Information.  In such a case, you are strictly 
prohibited from downloading, photocopying, distributing or otherwise using this 
message, its contents or attachments in any way.  If you have received this 
message in error, please notify us immediately by replying to this e-mail and 
delete the message from your mailbox.  Information contained in this message 
that does not relate to the business of SEAKR is neither endorsed by nor 
attributable to SEAKR.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users