On Wed, Sep 04, 2002 at 02:54:55PM +0200, Peter T. Breuer wrote:
> > > Sure. So what? What's wrong with a O_DIRDIRECT flag that makes all
> > > opens retrace the path from the root fs _on disk_ instead of from the
> > > directory cache?
> >
> > Did you read Antons post about this?
>
> Yep. My reply is out there.
I think you missed one. Anton explained in detail what NTFS would have
to do to write a single byte if _nothing_ was cached on the client. I
think it failed to mention that the whole operation would have to be
executed with a lock - so mouch for distributed operation.
> > Why do you want a filesystem if you're not going to use any filesystem
> > operations? If all you want to do is to split your shared device into
>
> But I said we DO want to use FS operations. Just nowhere near as often
> as we want to treat the data streaming through the file system (i.e.
> "strawman"), so the speed of metadata operations on the FS is not
> apparently an issue.
Remember that append causes metadata updates, so the only thing you can
do without worrying about the speed of metadata updates is read/rewrite.
(assuming you hack the filesystems to turn of timestamp-updates)
And even those operations are highly dependent on "metadata operations"
- they need metadata to know where to read/rewrite. Again, read Antons
post about this.
> > multipe (static) logical units use a logical volume manager.
>
> My experiments with the current lvm have convinced me that it is a
> horror show with no way sometimes of rediscovering its own consistent
> state even on one node. I'd personally prefer there to be no lvm, right
> now!
Currently there is no volume-manager with cluster support on linux
(unless Veritas has one?), but both Sistina and IBM are working on it
for LVM2 and EVMS - I'm sure patches will be accepted to speed up the
process.
> > If you _do_ need a filesystem, use something like gfs. Have you looked
> > at it at all?
>
> The point is not to choose a file system, but to be able to use
> whichever one is preferable _at the time_. This is important.
> Different FSs have different properties, and if one is 10% faster than
> another for a different data load, then the faster FS can be put
> in and 10% more data can be collected in the time slot allocated (and
> these time slots cost "the earth" :-).
Are you refering to that some filesystems can handle certain workloads
better than others? E.g. reiserfs is really fast for manipulating
directory-structures, adding new files or removing old ones? But didn't
you say that all you cared about was read and rewrite? That all other
filesystem-operations were so rare that nobody would notice?
In addition to this beeing technically impossible (to create a _working_
solution) I think the motivation is seriously flawed. The "solution"
you're proposing wouldn't be suitable for any viable problem.
-- Ragnar Kjørstad Big Storage - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:21 EST