From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 23 Aug 2010 08:24:16 +0200 (CEST) Date: Mon, 23 Aug 2010 08:24:16 +0200 From: Heinz Diehl Message-ID: <20100823062416.GA6456@fancy-poultry.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> <20100822215142.GA16551@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100822215142.GA16551@tansi.org> 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 23.08.2010, Arno Wagner wrote: > > 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. > If that means I am back to ext2 safety levels, then I can > live with that. You could turn the hardware wb cache of your harddrive off and leave the barriers off too.. I've been running my disks a liftime without barrier support without any hassle, because it improves speed and interactivity a lot, but I must admit that my machines are all UPS secured. /dev/mapper/root on / type xfs (rw,noatime,logbsize=256k,logbufs=2,nobarrier) /dev/mapper/home on /home type xfs (rw,noatime,logbsize=256k,logbufs=2,nobarrier)