On Oct 8, 2014, at 10:28 AM, Jelle de Jong <jelledejong@xxxxxxxxxxxxx> wrote: > Hello everyone, > > I been using CF cards for almost more then 7 years now with ext > file-system without any major problems on ALIX boards. > > Last year I took 30 other systems in production with ext4 and the CF > cards been dropping out pretty fast, it may have been a bad batch but > I do want to look at it. I don't think the devices writes a lot of IO > (is there a tool that can give me some useful numbers for say 24H or a > week? iotop, atop, sysstat doesn?t seem suited for long term IO write > monitoring, but maybe I am misusing them and can use some help here) You can see in the ext4 superblock the amount of data that has been written to a filesystem over its lifetime: dumpe2fs -h /dev/vg_mookie/lv_home dumpe2fs 1.42.7.wc2 (07-Nov-2013) Filesystem volume name: home Last mounted on: /home : : Lifetime writes: 27 GB : : Note that this number isn't wholly accurate, but rather a guideline. IIRC it is not updated on disk all the time, so may lose writes. You can also get this information from /sys/fs/ext4 including data just for the current mount: # grep . /sys/fs/ext4/*/*_write_kbytes /sys/fs/ext4/dm-0/lifetime_write_kbytes:77632360 /sys/fs/ext4/dm-0/session_write_kbytes:7124948 /sys/fs/ext4/dm-19/lifetime_write_kbytes:28081448 /sys/fs/ext4/dm-19/session_write_kbytes:16520 /sys/fs/ext4/dm-2/lifetime_write_kbytes:60847858 /sys/fs/ext4/dm-2/session_write_kbytes:7739388 /sys/fs/ext4/dm-7/lifetime_write_kbytes:22385952 /sys/fs/ext4/dm-7/session_write_kbytes:6379728 /sys/fs/ext4/sda1/lifetime_write_kbytes:835020 /sys/fs/ext4/sda1/session_write_kbytes:60848 > I mount root with the following options: > > /dev/disk/by-uuid/09a04c01-64c6-4600-9e22-525667bda3e3 on / type ext4 > (rw,noatime,user_xattr,barrier=1,data=ordered) > > # dumpe2fs /dev/sda1 > http://paste.debian.net/hidden/e3f81f11/ > > Are there kernel options to avoid synchronous disk writes? As > suggested here: http://www.pcengines.ch/cfwear.htm If you increase the journal commit interval (e.g. 30s) you can reduce the number of times a block needs to be written to the journal. The drawback is that you also increase the amount of un-sync'd metadata that would be lost in case of a crash. This usually means the data would also be lost, unless you are using a database-like workload that overwrites the same files continuously. > Is there a list of other kernel options I can optimise to limit any cf > wear? The devices don't use > > Kind regards > > Jelle de Jong > > > _______________________________________________ > Ext3-users mailing list > Ext3-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/ext3-users Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
