Mailing List Archive

On Mon, 25 Jan 1999, Stephen C. Tweedie wrote:
> > There's the possibility of external RAID devices that will undo all that
> > work for you by doing buffering and ACK's by themselves, then turning
> > around to talk to disks with data in cache.
>
> Not on ANY decent storage systems.
Network Appliance filers (which are, to my mind, the ultimate external
RAID device 8^) do this, but of course they store such transactions
in NVRAM. LLike Stephen said, the OS can assume that the disk will do
the right thing, because disks do do the right thing in this regard.
He knows of which he speaks.
--
Todd Graham Lewis 32°49'N,83°36'W (800) 719-4664, x2804
******Linux****** MindSpring Enterprises tlewis@mindspring.net
"Those who write the code make the rules." -- Jamie Zawinski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Hello!
On Mon, 25 Jan 1999, Stephen C. Tweedie wrote:
> Absolutely, but that's not the point: the point is that the Unix API
> does not allow applications to specify such a partial order on IO. Raw
> IO, O_SYNC and friends, and fsync() are about all an application can
> use.
A clever implementation of the API should be almost enough for most apps'
needs: I think that fsync should flush the buffer associated with the file
and place an io ordering marker in the queue. Once all associated buffers
have finished flushing, fsync returns either success or EIO. The
application then knows that an error occurred on one of the blocks written
between fsync()s. Of course, with the way ext2 currently implements
fsync(), this isn't terribly efficient, but here's a suggestion (one I
just started playing with this weekend): make the cache of indirect blocks
associated with an inode a virtually indexed cache a la page cache rather
than using the buffer cache. I'm going about this by first abstracting
the page cache into a virtual object cache. For this to be truely useful,
it'll require the underlying block io scheme to be leaner (the 'think of
buffer_heads as io requests' plan). This is just a little brain dump at
present...
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

In article <linux.kernel.199901222150.VAA05394@dax.scot.redhat.com>,
Stephen C. Tweedie <sct@redhat.com> wrote:
>Hi,
>
>On Thu, 21 Jan 1999 21:39:26 +0100 (MET), Gerard Roudier
><groudier@club-internet.fr> said:
>
>> Providing integrity using only a synchronous IO semantic is so costly for
>> performances that I donnot even want to think for a second to such an
>> approach.
>
>Interesting to hear you say this, since that is _precisely_ what you get
>if you are running a large DB like Oracle or Informix on raw devices.
>All raw devices are _necessarily_ synchronous, and yet these devices are
>suggested as a means of improving performance.
Hopefully nobody is still saying this. In the old days, when
processors were slow and DMA didn't exist, copies were bad,
but I don't think that any systems built in the last decade
suffer from this disadvantage.
People were still saying this when I worked for the idiots at Sybase
about a decade ago, and they (we) kept putting our feet in it when
our victims would try that out, only to realize that scribbling on
a filesystem was considerablty faster (if somewhat less reliable)
than scribbling on raw partitions.
____
david parsons \bi/ Fast or Safe, take yer choice.
\/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

In article <788n75$10m$1@palladium.transmeta.com> you wrote:
> Actually, it is better than that: as long as the commit record cannot
> pass the data records, you can roll back to a consistent state.
Yes, but in the overall picture of transactions it might be posible that u
have acknowledged a super-transaction already. So the changes of that
transaction will only partly be written to the system.. bad thing.. lets
create some money with that :)
Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/