[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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.


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.