From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tansi.org (ns.km10532-04.keymachine.de [87.118.102.195]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 25 Aug 2010 04:40:05 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by tansi.org (Postfix) with ESMTPA id 0FF99212804A for ; Wed, 25 Aug 2010 04:40:05 +0200 (CEST) Date: Wed, 25 Aug 2010 04:40:04 +0200 From: Arno Wagner Message-ID: <20100825024003.GA27253@tansi.org> References: <20100817184635.GA17921@tansi.org> <4C6BC751.10506@redhat.com> <20100818141208.GB1847@tansi.org> <4C6BF27C.1050305@redhat.com> <20100818154419.GA3349@tansi.org> <20100822195259.GA13530@tansi.org> <1282513364.3227.16.camel@fermat.scientia.net> <4C721F98.2090700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C721F98.2090700@redhat.com> Subject: Re: [dm-crypt] dm-crypt flush-to-disk freezes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Mon, Aug 23, 2010 at 09:13:28AM +0200, Milan Broz wrote: > On 08/22/2010 11:42 PM, Christoph Anton Mitterer wrote: > > On Sun, 2010-08-22 at 21:52 +0200, Arno Wagner wrote: > >> What do I lose with barriers off? > > data security ;) > > > > > > In case of the filesystem barriers (not the IO barriers, which are > > different AFAIK) they're used to make sure, that the COMMITS in the > > journal are written after the journal is correctly flushed out. > > Slight confusion here. > > FS uses flush (called by fsync for example), it is currently implemented > using IO barrier. Ok. So is a process calls fsync on a file, this happens. > After this operation, FS code can be sure that preceding barrier > reached disk. > (Device-mapper internally waits for all IO to finish, processing always > one barrier at a time and queuing following requests.) Seems there is some backlog in my case. What I find curious is that plain ext3 on RAID1 (same disks, different partitions) does not cause problems. I would expect that an fsync blocks the disk, not only the partition. Maybe having the system and data on different filesystems just reduced the backlog enough. > If you disable it, data simply reach disk later and e.g. unexpected > power loss can cause quite serious data loss. > But you probably see better performance. I went back to ext2 for the time being. This is used only to work on Word documents. The data gets copied off imediately anyways and I have a backup of the complete VM in case something breaks. > So disabling barriers helps in your case? Then probably some tuning > of fs can help also. I would expect that. Especially more aggressive flushing should help. Will look into it when I have time. For the moment I am happy to have a solution that does not increase the considerable pain level word manages to cause all by itself (I am a LeTeX person....). > (There is ongoing discussion about reimplementing barriers in block > layer, maybe it will slightly help here too.) I find them quite a pain sometimes, especially when writing large amounts of data. I used to have a fine-tuned parameter set that managed to almost completely avoid emergency flushes, while having minimal impact on performance. Then the kernel devs decided to take the interface away. I am still mad at them for that. Should probably look at this again. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier