Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
James Gray wrote: mount ext3 with options: journal=data,barrier=1,noatime,user_xattr Do you actually mean "data=journal"? Yes I do, my apologies. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
On 12/06/2008, at 2:28 PM, Erik de Castro Lopo wrote: Erik de Castro Lopo wrote: Does anyone know of a Linux filesystem which allows online fsck on a disk that is currently mounted read/write? Rather than asking for a filesystem, maybe I should be asking for better use of the one we're currently using, Ext3. How about mounting everything yo can read only, then you should be able to umount read write filesystems and fsck them. http://chesterton.id.au/blog/ http://barrang.com.au/ -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
On Thursday 12 June 2008 15:23:29 [EMAIL PROTECTED] wrote: > > Another option I'm looking into is the possibility of running > > the sync command at known idle times which follow a activity > > which results in disk writes. > > > > > > that should help. > how about just not loosing power? Ie, some sort of built-in UPS/battery > etc? It might be possible to keep the machine alive with a built in battery > long enough for sync to finish. > I know its a work around, but this is a pretty tricky problem. Would not it be better to (1) define the problem (2) define solution(s) (3) implement rather than jumping in with both feet and squarabling for a solution? EG I've got video systems recording divers on an oil rig. Power, waves, power, power and power are grave issues. I boot RAM fs from RO squashfs image with write of video data to flash/disk. This works very well, but is very tailored to this specific need. EG you could easily implement a battery-primary system that would never have a power outage and lead-acid batteries are marvelous sinks of noise. There are numerous ways to achieve this even normal power supplies that are 12v or 24v input. etc James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
On 12/06/2008, at 5:00 PM, Glen Turner wrote: Erik de Castro Lopo wrote: Does anyone have anything else to suggest? mount ext3 with options: journal=data,barrier=1,noatime,user_xattr Create the fs with a bigger journal than usual, this will improve performance with journal=data. Do you actually mean "data=journal"? I only see "update" and "inum" as valid values (man mount) for the "journal" option. Maybe I'm missing something...it's getting late and I missed lunch so I'm running on caffeine!! Cheers, James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
Erik de Castro Lopo wrote: Does anyone have anything else to suggest? mount ext3 with options: journal=data,barrier=1,noatime,user_xattr Create the fs with a bigger journal than usual, this will improve performance with journal=data. Our scientists often forgo filesystems entirely if the application is simple (eg, data collection). For example, they'll zero the partition at the start. To record an observation they'll seek to a position based on the time (or observation number reported by the data hardware) and sync write the fixed-length observation with a checksum. Note that Linux's performance with sync-ing is poor on a multi-use machine (since all buffers are synced, not just the application's buffers). Note that barrier=1 won't work with LVM or DM, you need a real partition. You might want to consider a distro like OpenWrt which minimises the amount of incidental disk I/O done by the distribution and allows a definite split between a read-only partition and a read-write partition. The the amount of read-write disk to be recovered will be smaller (since read-only partitions don't need recovery). -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
On Thu, Jun 12, 2008, Adrian Chadd wrote: > Invest in small UPSes and cleanly shut the server down on shutdown? > > Can you enable entire journalling, rather than just metadata journalling? > > Can you disable write-caching on the disks, so the disks aren't lying > when they say they've committed some stuff to disk? I seem to recall there > are brands of disks which will go to great lengths to lie to you that > the data is on the disk when its still in cache, all in the name of > (windows) performance. One more option is enabling barriers with -o barrier=1 (for a performance hit of perhaps 30%). The LWN article at http://lwn.net/Articles/283161/ (which is where my knowledge of the subject comes from) does not link to real use-cases where this has corrupted file systems but apparently not having them has been shown to cause corruption fairly regularly in torture tests. -Mary -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
Erik de Castro Lopo wrote: Another option I'm looking into is the possibility of running the sync command at known idle times which follow a activity which results in disk writes. that should help. how about just not loosing power? Ie, some sort of built-in UPS/battery etc? It might be possible to keep the machine alive with a built in battery long enough for sync to finish. I know its a work around, but this is a pretty tricky problem. dave -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
On Thu, Jun 12, 2008, Erik de Castro Lopo wrote: > In the above situation we are seeing machines have difficulty > when coming up after a powerloss. I suspect that we end up with > problems that even Ext3's journalling isn't enough to cope with > and I suspect that its actually the loss of disk metadata which > is causing the problems. [snip] > Does anyone have anything else to suggest? Invest in small UPSes and cleanly shut the server down on shutdown? Can you enable entire journalling, rather than just metadata journalling? Can you disable write-caching on the disks, so the disks aren't lying when they say they've committed some stuff to disk? I seem to recall there are brands of disks which will go to great lengths to lie to you that the data is on the disk when its still in cache, all in the name of (windows) performance. Its funny, as the whole argument with the ext3 journalling block device versus the XFS journalling was to work better on PC-class hardware. (Ie, when you don't have enormous PSU Capacitors and an NMI which get triggered on power-loss, giving you just enough juice to tell the disk controllers to -STOP- and not scribble random crap over important metadata sections. God, where'd that email get to?) Adrian (Anyone remember why Linux ext2's defaults versus BSD FFS's defaults were so bad?) -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA - -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] : Increasing filesystem reliability (was : Filesystem which allows online fsck?)
Erik de Castro Lopo wrote: > Does anyone know of a Linux filesystem which allows online > fsck on a disk that is currently mounted read/write? Rather than asking for a filesystem, maybe I should be asking for better use of the one we're currently using, Ext3. The application is one when we're using real hard disks in an envionment where we can expect the machines to lose power unexpectedly (if that makes sense). In particular we can not expect to always have a clean shutdown. In the above situation we are seeing machines have difficulty when coming up after a powerloss. I suspect that we end up with problems that even Ext3's journalling isn't enough to cope with and I suspect that its actually the loss of disk metadata which is causing the problems. With the above in mind, I've been looking at the mount options for Ext3 and we are currently testing the following: dirsync - Sync directory metadata to disk. noatime - Updating atime results in a disk write and we're trying to reduce the number of non-essential disk writes. nodiratime - As above. Another option I'm looking into is the possibility of running the sync command at known idle times which follow a activity which results in disk writes. Does anyone have anything else to suggest? Cheers, Erik -- - Erik de Castro Lopo - "I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java." -- http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
