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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
