From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Lincoln Yeoh'" <lyeoh(at)pop(dot)jaring(dot)my> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | AW: Re: New Linux xfs/reiser file systems |
Date: | 2001-05-07 10:10:03 |
Message-ID: | 11C1E6749A55D411A9670001FA6879633682B1@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I think it's worth noting that Oracle has been petitioning the
> > kernel developers for better raw device support: in other words,
> > the ability to write directly to the hard disk and bypassing the
> > filesystem all together.
>
> But there could be other reasons why Oracle would want to do
> raw stuff.
The reasons are:
1. Most Unixen now have shared (between several machines) raw devices
Oracle needs this for their shared everything Parallel Server. Only 2 Unixen
that I know of have shared filesystems (IBM gpfs and Sun Veritas) (both are rather new)
2. The allocation time for raw devices is by far better (near instantaneous) than
creating preallocated files in a fs. Providing 1 Tb of raw devices is a task
of minutes, creating 1 Tb filsystems with preallocated 2 Gb files is a task of
hours at best.
3. absolute control over writes and page location (you don't want interleaved pages)
4. Efficient use of buffer memory. Usual use of filesystems buffers the disk pages twice,
one copy in the db buffer pool, one in the OS file cache.
5. async raw IO (most Unixes provide async raw IO on raw devices, only some provide
raw IO on filesystem files).
(async IO has 2 advantages: CPU work can be done while waiting for IO and
IO can complete within one OS timeslice (20 us). This is possible with modern
disk systems, that have large caches)
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Alessio Bragadini | 2001-05-07 10:19:48 | A problem with new pg_dump |
Previous Message | Tony Grant | 2001-05-07 08:57:29 | Re: Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars? |