gjournal +UFS - anyone actually use it?

[Wojciech Puchar]

>
> 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: <Intel ICH7 AHCI SATA controller> 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: <ST500NM0011 PA08> 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?