How to mount reiserfs with a relocated journal?

How to mount reiserfs with a relocated journal?

[Doug Bazarnic]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Hello,  
 
I'm running RH7.3 with a patched 2.4.21 kernel (03-relocation-8.diff.gz
<ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21/03-relo
cation-8.diff.gz> ).    
 
I can't get my relocated journal drive to mount.   Are there any special
arguments I have to pass to mount?
 
Mount complains that it can't find a superblock on /dev/sdb1
 
I used  mkreiserfs /dev/sdb1 -j /dev/hda1 .   
 
/dev/sdb1 is my 73 gig Scsi HD, and /dev/hda1 is a 512 meg compact flash
card hooked up to the ide port.
 
Mkreiserfs works fine, writes the journal to /dev/hda1, syncs and says
"OK"
 
Any help would be appreciated!
 
 
Thanks so much,
 
Doug

RE: How to mount reiserfs with a relocated journal? -- Figured out

[Doug Bazarnic]

I had forgotten to run lilo to actually USE the patched kernel.  Oops!
:)

Duh... 

Any way, is there a down side to using a large journal?  8193 vs ~125000
block size?   Right now, I've allocated the entire 512 meg flash card
for the journal size.   


Thanks for you help,

Doug




-----Original Message-----
From: Doug Bazarnic [mailto:doug@cavecreek.net] 
Sent: Thursday, July 10, 2003 7:13 PM
To: reiserfs-list@namesys.com
Subject: How to mount reiserfs with a relocated journal?

Hello,  
 
I'm running RH7.3 with a patched 2.4.21 kernel (03-relocation-8.diff.gz
<ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21/03-relo
cation-8.diff.gz> ).    
 
I can't get my relocated journal drive to mount.   Are there any special
arguments I have to pass to mount?
 
Mount complains that it can't find a superblock on /dev/sdb1
 
I used  mkreiserfs /dev/sdb1 -j /dev/hda1 .   
 
/dev/sdb1 is my 73 gig Scsi HD, and /dev/hda1 is a 512 meg compact flash
card hooked up to the ide port.
 
Mkreiserfs works fine, writes the journal to /dev/hda1, syncs and says
"OK"
 
Any help would be appreciated!
 
 
Thanks so much,
 
Doug

Re: How to mount reiserfs with a relocated journal? -- Figured out

[Oleg Drokin]

Hello!

On Thu, Jul 10, 2003 at 08:26:19PM -0700, Doug Bazarnic wrote:

> Any way, is there a down side to using a large journal?  8193 vs ~125000
> block size?   Right now, I've allocated the entire 512 meg flash card
> for the journal size.   

Well, if your flash card will die, you have possibly more data to loose.
Also keep in mind that journal header gets updated for every transaction
(in fact the should be batched so this should not be so hard hit, esp.
for large journals, but still).

Hm, I think for large journals you may also want to increase journal flushtime.
Unfortunatelly this is hardwired to be once in 5 seconds.
fs/reiserfs/journal.c and look for "interruptible_sleep_on_timeout(&reiserfs_commit_thread_wait, 5 * HZ) ;",
change 5 to whatever number of seconds you may want. May and will lead to increased memory consumption when
combined with large journals, though.

Bye,
    Oleg

RE: How to mount reiserfs with a relocated journal? -- Figured out

[Doug Bazarnic]

I've heard that using flash card memory (solid state devices) increases
performance -- roughly 20-30%.   With the slower write speeds of 4 - 6
MByte/sec,  I'm not sure if it would truly be faster.

I haven't time to test anything yet myself.

The flash card is supposed to have a life greater than 1 million writes
to it, so I don't know how well it will hold up in real life.  We're
just looking for more speed.   We tend to rotate our database servers
every 3 months or so, for something newer and faster.

If the flash card does die, can't we just do a tree rebuild?

Doug


-----Original Message-----
From: Oleg Drokin [mailto:green@namesys.com] 
Sent: Thursday, July 10, 2003 10:47 PM
To: Doug Bazarnic
Cc: reiserfs-list@namesys.com
Subject: Re: How to mount reiserfs with a relocated journal? -- Figured
out

Hello!

On Thu, Jul 10, 2003 at 08:26:19PM -0700, Doug Bazarnic wrote:

> Any way, is there a down side to using a large journal?  8193 vs
~125000
> block size?   Right now, I've allocated the entire 512 meg flash card
> for the journal size.   

Well, if your flash card will die, you have possibly more data to loose.
Also keep in mind that journal header gets updated for every transaction
(in fact the should be batched so this should not be so hard hit, esp.
for large journals, but still).

Hm, I think for large journals you may also want to increase journal
flushtime.
Unfortunatelly this is hardwired to be once in 5 seconds.
fs/reiserfs/journal.c and look for
"interruptible_sleep_on_timeout(&reiserfs_commit_thread_wait, 5 * HZ)
;",
change 5 to whatever number of seconds you may want. May and will lead
to increased memory consumption when
combined with large journals, though.

Bye,
    Oleg

Re: How to mount reiserfs with a relocated journal? -- Figured out

[Oleg Drokin]

Hello!

On Thu, Jul 10, 2003 at 10:57:32PM -0700, Doug Bazarnic wrote:

> I've heard that using flash card memory (solid state devices) increases
> performance -- roughly 20-30%.   With the slower write speeds of 4 - 6
> MByte/sec,  I'm not sure if it would truly be faster.

This is well believable. You save on seeks to journal.

> The flash card is supposed to have a life greater than 1 million writes
> to it, so I don't know how well it will hold up in real life.  We're
> just looking for more speed.   We tend to rotate our database servers
> every 3 months or so, for something newer and faster.

You can try battery backed RAM which is going to be even faster.

> If the flash card does die, can't we just do a tree rebuild?

Yes, you can. Only if it was holding some valuable transaction,
you may not get it.

Bye,
    Oleg

Re: How to mount reiserfs with a relocated journal? -- Figured out

[Russell Coker]

On Fri, 11 Jul 2003 15:57, Doug Bazarnic wrote:
> I've heard that using flash card memory (solid state devices) increases
> performance -- roughly 20-30%.   With the slower write speeds of 4 - 6
> MByte/sec,  I'm not sure if it would truly be faster.

As Oleg mentions having 0 seek time will be a huge win for flash.  However if 
you have a 15,000rpm disk doing nothing but journalling (so the journal is 
only on the first few cylinders) the seek time will also be very low.

> The flash card is supposed to have a life greater than 1 million writes
> to it, so I don't know how well it will hold up in real life.  We're

Last time I looked into this I had some servers that were sustaining >1M/s of 
disk writes 24*7.  If that is all journalled and there's a 256M journal then 
each block would be written once every four minutes.  If the flash card would 
last exactly 1M writes for each block (something I doubt) then it would last 
4M minutes which is over 7 years.  You may want to sustain a higher load than 
I did, but it still is quite likely that the flash will last the 3 months you 
require.

However I believe that the the umem cards are a better choice.  They have a 
sustained write speed of 240MB/s (much faster than flash) and because they 
are battery backed RAM devices they support an unlimited number of writes.  
The best thing is that they are specifically designed for tasks just like 
this one.  See the following URL for details:
http://www.micromemory.com/

I am not associated with umem in any way, I just determined after extensive 
research that they were the best option for one of my clients.  My client 
then decided to just purchase more hard drives instead (at much greater 
expense).  :(

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: How to mount reiserfs with a relocated journal? -- Figured out

[Russell Coker]

I'm replying to the list because I believe that this will interest other 
people and that it is not something you desired to keep secret.  Also if I 
get something wrong then someone will correct me.  ;)

On Fri, 11 Jul 2003 17:22, Doug Bazarnic wrote:
> Are you aware if these cards require drivers under linux?

There is a driver in the stock kernel.  Enable CONFIG_BLK_DEV_UMEM.

> I've just read the literature on the flash cards and they mtbf is
> 1,000,000 hours, not writes.

That sounds reasonably good, although it might be based on "typical usage 
patterns"...

BTW  Did you know that disk life depends on altitude?  If you run a hard drive 
at the top of a mountain or below sea level then that may dramatically 
decrease it's life.  Due to manufacturing issues some drives in a series will 
work better in mountains than others, manufacturers are capable of supplying 
such drives if they feel inclined.  If you get a drive that due to 
manufacturing issues will work best below sea level and run it on a mountain 
you won't expect it to last the MTBF time.

Unless you are doing exactly what the manufacturer thinks a "typical" user 
will do then don't count on getting a MTBF.

> Do you know if having a larger journal slows things down, or speeds
> things up?

If there is no seek time (as is the case with Flash and umem cards) then there 
is no penalty to making it larger AFAIK.  Whether there is any benefit is 
another issue.

For my client I designed a system with a 1G umem card which would be used for 
32M journals for two important file systems and the other 960M was to be used 
for a partition mounted under /var/spool for performance critical data that 
was to be written synchronously.  I judged that 960M of virtually instant 
storage (that did not affect the speed of the other partitions in the RAID 
device in any way) would be of much greater benefit than larger journals.

If you are using a database that has it's own journalling system then maybe 
you could have the database journal on the umem device, which may give better 
performance gains than anything you could do at the FS level.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page