From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 7 09:08:30 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5441B89B for ; Thu, 7 Mar 2013 09:08:30 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id C578DCB4 for ; Thu, 7 Mar 2013 09:08:29 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r2798IYk009825; Thu, 7 Mar 2013 10:08:18 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r2798H4l009821; Thu, 7 Mar 2013 10:08:18 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 7 Mar 2013 10:08:17 +0100 (CET) From: Wojciech Puchar To: Mark Saad Subject: Re: gjournal +UFS - anyone actually use it? In-Reply-To: <44621188-C3CF-44EC-BC94-CF85530C9423@longcount.org> Message-ID: References: <15BA8CB5-A10A-4FA9-AC5F-1BA2B7720E5E@longcount.org> <44621188-C3CF-44EC-BC94-CF85530C9423@longcount.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 07 Mar 2013 10:08:18 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 09:08:30 -0000 > > Interesting I will have to try this; can you post the exact test steps . Also what type of controller were you using and what kernel / version . intel atom D525 builtin ahci0: port 0x20b8-0x20bf,0x20cc-0x20cf,0x20b0-0x20b7,0x20c8-0x20cb,0x20a0-0x20af mem 0xf0284000-0xf02843ff irq 18 at device 31.2 on pci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 (BTW - no idea why it previously was known as ad4 as i've never ever run this machine without AHCI driver ;) create partition. copy kernel sources tarball here. now on that partition rm -rf * then write a script test.sh #!/usr/local/bin/bash a=0 while [ $a -lt 12 ];do mkdir $a cd $a a=$[a+1] tar xpf ../yourtarball.tar.gz cd .. done run it with (after chmod 700) time ./test.sh rerun a test on different conditions. >> >> SU+J makes sure that metadata will get consistent. NOT DATA. And this is quite a mess if you get UPS failure under high load. >> >> gjournal does journal everything. >> > > Not exactly, ufs mounted with default options insures data is written sync and metadata asynchronous . Standard Softupdate (no journal) improves upon this by limiting what ops need to write to the disk. It had some short falls for edge case operations; which softupdate journal resolved by journaling the metadata ops that were not protected / covered by standard softupdate . > > See > http://jeffr-tech.livejournal.com/24357.html gjournal recommends using async, because it takes care of the rest. my tests using pendrive as log device (slow but OK) confirmed my opinion, at least roughly. >> SSDs are not expensive today. i can get 128GB SSD and create 20GB journal just to limit wear. and possibly use the rest of SSD to store read-intensive data. >> > > I wonder if how trim / no trim effects the journal wear . not at all. gjournal writes sequentially. best case for SSD - just write subsequent flash blocks and older gets freed completely and erase it. >> gjournal doesn't seem to be elegant in case of journal failure (i simulated it with forced removal of ramdisk with mdconfig). >> >> TONS of messages in logs, but still - no data loss, just you have to shutdown system, boot from pendrive, remove journal, fsck (just for sure), and then add journal again > > > I would be careful of using the md for the journal . > >Something makes me think it will play nicer when you remove that then a real failure . Try a USB stick for the journal; tried. same results. md was only for testing, doesn't make any sense in production setup as it's volatile. > Also when testing su+j I ran the following test case . Extract ports via portsnap extract , build world with -j4 . Let the box warm up the yank the power and then boot the box back up and see what happens . and? didn't you end with empty - but existing - object files that make things it is properly compiled programs?