Re: [dm-crypt] dm-crypt flush-to-disk freezes

[Arno Wagner <arno@wagner.name>]

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