Recomended FS

[Ben-Nes Michael]

Hi

I'm upgrading the DB sever hardware and also the Linux OS.

My Questions are:

1. What is the preferred FS to go with ? EXT3, Reiseref, JFS, XFS ? ( speed,
efficiency )
2. What is the most importent part in the Hardware ? fast HD, alot of mem,
or maybe strong cpu ?

Thanks in Advance

--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: [phone]
Fax: [phone]
http://www.canaan.net.il
--------------------------
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[scott.marlowe]

On Fri, 24 Oct 2003, Scott Chapman wrote:

On Friday 24 October 2003 16:23, scott.marlowe wrote:

Right, but NONE of the benchmarks I've seen have been with IDE drives with
their cache disabled, which is the only way to make them reliable under
postgresql should something bad happen. but thanks for the benchmarks,
I'll look them over.

I don't recall seeing anyone explain how to disable caching on a drive in this
thread. Did I miss that? 'Would be useful. I'm running a 3Ware mirror of 2
IDE drives.

Scott

Each OS has it's own methods, and some IDE RAID cards don't give you
direct access to the drives to enable / disable write cache.

On Linux you can disable write cache like so:

hdparm -W0 /dev/hda

back on:

hdparm -W1 /dev/hda
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Greg Stark]

"scott.marlowe" <sc***********@ihs.com> writes:

Sweet. It may be that the promise is turning off the cache, or that the
new generation of IDE drives is finally reporting fsync correctly. Was
there a performance difference in the set with write cache on or off?

Check out this thread. It seems the ATA standard does not include any way to
make fsync work properly without destroying performance. At least on linux
even that much is impossible without disabling caching entirely as the
operation required isn't exposed to user-space. There is some hope for the
future though.

http://www.ussg.iu.edu/hypermail/lin...10.2/0163.html

The other interesting possibility is that Freebsd with soft updates
helped things remain salvageable in the cache enabled case (as some
writes *must* be lost at power off in this case)....

Free BSD may be the reason here. If it's softupdates are ordered in the
right way, it may be that even with write caching on, the drives "do the
right thing" under BSD. Time to get out my 5.0 disks and start playing
with my test server. Thanks for the test!

I thought soft updates applied only to directory metadata changes.

--
greg
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Bruce Momjian]

Greg Stark wrote:

"scott.marlowe" <sc***********@ihs.com> writes:

Sweet. It may be that the promise is turning off the cache, or that the
new generation of IDE drives is finally reporting fsync correctly. Was
there a performance difference in the set with write cache on or off?

Check out this thread. It seems the ATA standard does not include any way to
make fsync work properly without destroying performance. At least on linux
even that much is impossible without disabling caching entirely as the
operation required isn't exposed to user-space. There is some hope for the
future though.

http://www.ussg.iu.edu/hypermail/lin...10.2/0163.html

I thought the operating system has to write the block and force it to
disk, and that happened the same with SCSI and IDE. I didn't assume the
drive would associate multiple blocks with the fsync.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Greg Stark]

"scott.marlowe" <sc***********@ihs.com> writes:

Or a CPU frying, or a power supply dying, or a motherboard failure, or a
kernel panic, or any number of other possibilities. Admittedly, the first
line of defense is always good backups, but it's nice knowing that if one
of my CPUs fry, I can pull it, put in the terminator / replacement, and my
whole machine will likely come back up.

Well, note that in all of those cases the disk drive would still have a chance
to sync its buffers to disk. Linux isn't lying about fsync as far as its
buffers getting flushed, only the drive itself.

In theory even in those cases there's no guarantee of exactly how long the
drive will hold the buffers without committing them, but in practice I think
any sane drive will commit pretty damn soon or else normal power-off wouldn't
work.

--
greg
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Mark Kirkwood]

scott.marlowe wrote:

Was there a performance difference in the set with write cache on or off?

Yes - just in the process of a little study concerning this - I will
post some preliminary results soon

cheers

Mark
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Mark Kirkwood]

Maybe it is a little late to be posting on this thread - but I was doing
pgbench runs with a Raid 0 ATA system and thought the results might be
interesting.

So here they are : pgbench -c 5 -t 1000 -s 5, median of 3 runs on a
Dual PIII 700 512Mb 2x7200 RPM ATA 133 Promise TX200
(same method / Pg configuration parameters as Scott's):

2 disk Raid0 W0
66 tps

2 disk Raid0 W1
220 tps

I was expecting a slightly better result for W0 (write caching off),
mind you the point could be made that you get about half the performance
of the SCSI system - for about half the price.

And the W1 result - that's fast, when (or if) that little power saving
capacitor arrives for these drives we could see performance, reliability
*and* economy....

regards

Mark

scott.marlowe wrote:

MachineA Config1:
141 tps

MachineB Config1 W0:
60 tps

MachineB Config1 W1:
112 tps

MachineA Config2:
101 tps

MachineB Config2 W0:
44 tps

MachineB Config2 W1:
135 tps

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html