"Jeff V. Merkey" <[EMAIL PROTECTED]> writes:
> Cool. ORACLE is going to **SMOKE** on EXT2 with this change.
Hmm I don't see how ORACLE is going to **SMOKE**.
Last I looked ORACLE would need a query optimizer that always
would find the best possible index and much less overhead to **SMOKE**.
On Thu, Nov 23, 2000 at 01:01:25PM -0700, Jeff V. Merkey wrote:
> On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote:
> > Hi,
> >
> > On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
> > >
> > > I have not implemented O_SYNC in NWFS, but it looks like I need to
On Thu, Nov 23, 2000 at 01:01:25PM -0700, Jeff V. Merkey wrote:
On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote:
Hi,
On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
I have not implemented O_SYNC in NWFS, but it looks like I need to add it
"Jeff V. Merkey" [EMAIL PROTECTED] writes:
Cool. ORACLE is going to **SMOKE** on EXT2 with this change.
Pessimism
Hmm I don't see how ORACLE is going to **SMOKE**.
Last I looked ORACLE would need a query optimizer that always
would find the best possible index and much less overhead to
On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
> >
> > I have not implemented O_SYNC in NWFS, but it looks like I need to add it
> > before posting the final patches. This patch appears to force
Hi,
On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
>
> I have not implemented O_SYNC in NWFS, but it looks like I need to add it
> before posting the final patches. This patch appears to force write-through
> of only dirty inodes, and allow reads to continue from cache. Is
On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote:
Hi,
On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
I have not implemented O_SYNC in NWFS, but it looks like I need to add it
before posting the final patches. This patch appears to force
Hi,
On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
I have not implemented O_SYNC in NWFS, but it looks like I need to add it
before posting the final patches. This patch appears to force write-through
of only dirty inodes, and allow reads to continue from cache. Is this
Jeff,
>>Is this assumption correct, and does this comply with TPC rules for ORACLE and
>>other DBMS benchmarks? It looks like a good patch that will perform
>>very fast for O_SYNC.
Why would that be a problem? If you look at our benchmarks we normally use raw I/O
to bypass buffers altogether
On Wed, Nov 22, 2000 at 11:26:46AM +, Stephen C. Tweedie wrote:
> Hi,
>
> This final part of the O_SYNC patches adds calls to ext2, and to
> generic_commit_write, to record dirty buffers against the owning
> inode. It also removes most of fs/ext2/fsync.c, which now simply
> calls the
Hi,
This final part of the O_SYNC patches adds calls to ext2, and to
generic_commit_write, to record dirty buffers against the owning
inode. It also removes most of fs/ext2/fsync.c, which now simply
calls the generic sync code.
--Stephen
2.4.0test11.02.ext2-osync.diff :
---
Hi,
This final part of the O_SYNC patches adds calls to ext2, and to
generic_commit_write, to record dirty buffers against the owning
inode. It also removes most of fs/ext2/fsync.c, which now simply
calls the generic sync code.
--Stephen
2.4.0test11.02.ext2-osync.diff :
---
On Wed, Nov 22, 2000 at 11:26:46AM +, Stephen C. Tweedie wrote:
Hi,
This final part of the O_SYNC patches adds calls to ext2, and to
generic_commit_write, to record dirty buffers against the owning
inode. It also removes most of fs/ext2/fsync.c, which now simply
calls the generic sync
Jeff,
Is this assumption correct, and does this comply with TPC rules for ORACLE and
other DBMS benchmarks? It looks like a good patch that will perform
very fast for O_SYNC.
Why would that be a problem? If you look at our benchmarks we normally use raw I/O
to bypass buffers altogether (We
14 matches
Mail list logo
