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

[Scott Mewett <mewett@xxxxxxx>]

Hi,

My experience has shown me that just remounting an ext3 file system as ext2, 
doesn't fully disable all the journal bits.
You have to remove the journal as well.
I found that by watching the io debug output after remounting.

Thanks
Scott

On Feb 12, 2012, at 2:51 PM, Nick Couchman wrote:

> 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


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