mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: "Peter T. Breuer" <ptb@it.uc3m.es>
Cc: linux-kernel@vger.kernel.org
Subject: Re: (fwd) Re: [RFC] mount flag "direct"
Date: Fri, 6 Sep 2002 10:14:38 +0200	[thread overview]
Message-ID: <20020906101438.P781@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <200209051424.g85EOx105274@oboe.it.uc3m.es>; from ptb@it.uc3m.es on Thu, Sep 05, 2002 at 04:24:59PM +0200

Hi Peter,

after following this discussion I have some ideas which might
help you, but have to ask some more questions to find out clearly
what you are trying to do and express it in terms known to this
audience (which has failed so far, it seems).

1. You want to stream lots of data from a external source (which
   might be the network) to a bunch of machines which are
   connected to the same file system, where file system is a file
   system designed to be a local one (like FAT, NTFS, EXT2FS and
   so on). 
   
   
2. This filesystem is on a single device, which is attached to
   multiple machines, right?

3. You problem is, that your data arrives at some hundred MB/s
   right?

4. You want to solve it by force with using multiple machines to
   accept the data but sharing one super fast persistent device
   between them, ok?

5. To archieve 4. you cannot trust the caches and want to disable
   them?

6. Do you have a "master" machine or do you want each machine
   only peering each other?

7. Is fast bidirectional communication between the machines over
   some kind of wire/network possible?

I would suggest not to disable caches, but to use timed leases on
them to not penalize read only metadata operations (which are
~100% in your case).

If you read in some cache item, then you tell all your machines,
that you did so and want to use it read only for a time of X.
That is called a "lease", because other machines can tell you, that
you cannot use your cache anymore, because they need to
invalidate it. Leases can be broken by the grantor as opposed to
locks, which can only be released by the holder.

You can make the cache items very big and chunk them together to
reduce communication overhead, so performance should not be that
bad.

The writing case happens not that often you say, so you can make
it as easy as:

   1) Disallow new leases on the related items (if you cannot
      find out relations, than disallow ALL new leases).

   2) Breaking all related leases while telling them
      waiting for the lease clients to ACK the breakage.

   3) Do you update, flush it to disk.

   4) Reallow leases.

One of your problems are file extension and mtime updates.

This could be solved by restricting both to only one machine and
propagating the changes to the other machines. It's like an
allocator thread, if you are familiar with this concept.

These mechanisms are basically some kind of cache coherency
protocol. A special network between these machines just for that
might be worthwhile. 

You don't need to change ANY on-disk format.
You need to change the locks of kernel meta data caching into
leases.

Now you have sth. to work with, which is well known, is
performant in your use case and acceptable in OS terms.

But please answer my questions and doubts first, because I might
be way off, if my assumptions are wrong.

Hope this helps.

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

  parent reply	other threads:[~2002-09-06  8:12 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-03 21:48 Peter T. Breuer
2002-09-03 22:19 ` Anton Altaparmakov
2002-09-03 22:42   ` Peter T. Breuer
2002-09-03 22:52     ` Xavier Bestel
2002-09-03 23:44       ` Peter T. Breuer
2002-09-04  7:06         ` Alexander Viro
2002-09-04  9:02           ` Peter T. Breuer
2002-09-04 11:05             ` Anton Altaparmakov
2002-09-04 11:39               ` Peter T. Breuer
2002-09-04 14:13                 ` Anton Altaparmakov
2002-09-05 22:45                   ` Daniel Phillips
2002-09-05 23:06                     ` Anton Altaparmakov
2002-09-05 23:17                       ` Daniel Phillips
2002-09-05 23:24                         ` Anton Altaparmakov
2002-09-06  8:57                           ` Peter T. Breuer
2002-09-06  9:08                             ` Anton Altaparmakov
2002-09-06  9:17                               ` Peter T. Breuer
2002-09-06  9:50                                 ` Lars Marowsky-Bree
2002-09-06 14:10                                   ` Peter T. Breuer
2002-09-06 13:20                                 ` Helge Hafting
2002-09-06 13:22                                 ` Rik van Riel
2002-09-06 13:53                                   ` Peter T. Breuer
2002-09-06 15:32                                     ` Rik van Riel
2002-09-06 14:25                       ` Peter T. Breuer
2002-09-06 17:20                         ` Anton Altaparmakov
2002-09-06 17:33                           ` Daniel Phillips
2002-09-06 19:32                             ` Anton Altaparmakov
2002-09-06 18:29                           ` Peter T. Breuer
2002-09-06 19:30                             ` Anton Altaparmakov
2002-09-09 16:30                           ` Peter T. Breuer
2002-09-17 11:21                             ` Anton Altaparmakov
2002-09-05  8:30                 ` Helge Hafting
2002-09-05  8:43                   ` David Lang
2002-09-05 14:24                   ` Peter T. Breuer
2002-09-05 16:59                     ` David Lang
2002-09-05 23:08                     ` Daniel Phillips
2002-09-06  8:14                     ` Ingo Oeser [this message]
2002-09-06  9:06                     ` Helge Hafting
2002-09-04 12:49             ` Ragnar Kjørstad
2002-09-04 12:54               ` Peter T. Breuer
2002-09-04 13:22                 ` Ragnar Kjørstad
2002-09-05  3:36                 ` Edgar Toernig
2002-09-05  3:58                   ` Alexander Viro
2002-09-05 15:59                     ` [RFC] intent-based lookup (was: mount flag "direct") Andreas Dilger
2002-09-03 23:24     ` (fwd) Re: [RFC] mount flag "direct" David Lang
2002-09-04  4:27   ` Kevin O'Connor
2002-09-03 23:05 ` David Lang
     [not found] <02Sep6.161154edt.62237@gpu.utcc.utoronto.ca>
2002-09-07 13:36 ` Peter T. Breuer
     [not found] <20020909181724.GA31153@ravel.coda.cs.cmu.edu>
2002-09-09 18:58 ` Peter T. Breuer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020906101438.P781@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptb@it.uc3m.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome