Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Mar 2013 22:24:48 -0500
From:      Mark Saad <nonesuch@longcount.org>
To:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: gjournal +UFS - anyone actually use it?
Message-ID:  <44621188-C3CF-44EC-BC94-CF85530C9423@longcount.org>
In-Reply-To: <alpine.BSF.2.00.1303061144250.2276@wojtek.tensor.gdynia.pl>
References:  <alpine.BSF.2.00.1303051934550.3311@wojtek.tensor.gdynia.pl> <15BA8CB5-A10A-4FA9-AC5F-1BA2B7720E5E@longcount.org> <alpine.BSF.2.00.1303061144250.2276@wojtek.tensor.gdynia.pl>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mar 6, 2013, at 5:55 AM, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>=
 wrote:

>> I was using it to store large MySQL myisam tables , speed was acceptable a=
t the time .  I never had any fs corruption and it worked as expected .
>>=20
>> At the time I set it up I remember there was some chatter about how slow g=
journal was compared to ufs with softupdate .
>=20
> did some tests yesterday on 25GB partition.
>=20
> i simulated journal on SSD using 2GB malloc backed ramdisk (md0). UFS part=
ition mounted async as gjournal recommends.
>=20
> test: unpacking kernel sources to multiple directories until disk gets ful=
l
>=20
> simulates write heavy I/O.
>=20
> gjournal+SATA drive (seagate constellation ES 500GB) with write cache disa=
bled - 14 minutes 20 seconds.
>=20
> write cache enabled - 14 minutes 5 seconds (nearly no difference).
>=20
> UFS+journalled softupdates, no gjournal, disk write cache on - 26 minutes 4=
4 seconds. disk write cache off - was too lazy to wait after an hour.
>=20
> With gjournal it is not only faster, but it doesn't make other I/O activit=
y crawling.
>=20

Interesting I will have to try this; can you post the exact test steps . Als=
o what type of controller were you using and what kernel / version .

>=20
>>=20
>> Fast forward to today I almost always use ufs with softupdate journal , n=
ew in FreeBSD 9.0 and available as a patch to 6.x, 7.x , and 8.x
>=20
> The problem is as follows:
>=20
> SU+J makes sure that metadata will get consistent. NOT DATA. And this is q=
uite a mess if you get UPS failure under high load.
>=20
> gjournal does journal everything.
>=20

Not exactly, ufs mounted  with default options insures data is written sync a=
nd metadata asynchronous . Standard Softupdate (no journal) improves upon th=
is by limiting what ops need to write to the disk. It had some short falls  f=
or edge case operations; which softupdate journal resolved by journaling the=
 metadata ops that were not protected / covered by standard softupdate . =20=


See=20
http://jeffr-tech.livejournal.com/24357.html



>> This is better supported now , as more people use it in new 9.x builds  .=

>>=20
>>> i think about journal on SSD.
>>=20
>> I believe this is only and option in geom journal ,
>=20
> SSDs are not expensive today. i can get 128GB SSD and create 20GB journal j=
ust to limit wear. and possibly use the rest of SSD to store read-intensive d=
ata.
>=20

I wonder if how trim / no trim effects the journal wear .=20

> the way gjournal writes to journal device (sequential) is very friendly fo=
r SSD too.
>=20
> Small SLC-based SSD would be best but i don't see anything on the market w=
ith acceptable price for now.
>=20
>> I am not sure if you can relocate a suj journal to an alternate disk.
> no you can't. But still you will end with consistent metadata but not cons=
istent data. I recovered it but still it took a time and lots of checking.
>=20
>=20
>=20
>=20
> gjournal doesn't seem to be elegant in case of journal failure (i simulate=
d it with forced removal of ramdisk with mdconfig).
>=20
> TONS of messages in logs, but still - no data loss, just you have to shutd=
own system, boot from pendrive, remove journal, fsck (just for sure), and th=
en add journal again


I would be careful of using the md for the journal . Something makes me thin=
k it will play nicer when you remove that then a real failure .  Try a USB s=
tick for the journal; and pull it out while running your test case.  That to=
 me seams evil enough to break this setup .=20

Let me know what happens .

Also when testing su+j I ran the following test case . Extract ports via por=
tsnap extract , build world with -j4 . Let the box warm up the yank the powe=
r and then boot the box back up and see what happens .=20
--
Mark saad | mark.saad@longcount.org
=20=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44621188-C3CF-44EC-BC94-CF85530C9423>