public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Daniel Phillips <phillips@arcor.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Andreas Dilger <adilger@clusterfs.com>,
	Christopher Li <chrisl@vmware.com>,
	Alex Tomas <bzzz@tmi.comex.ru>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Improved inode number allocation for HTree
Date: Tue, 11 Mar 2003 13:45:15 +0300	[thread overview]
Message-ID: <3E6DBE3B.8030007@namesys.com> (raw)
In-Reply-To: <20030311031216.8A31CEFD5F@mx12.arcor-online.net>

Let's make noatime the default for VFS.

Daniel Phillips wrote:

>Hi Hans,
>
>On Tue 11 Mar 03 00:17, Hans Reiser wrote:
>  
>
>>What do you think of creating a new telldir/seekdir which uses filenames
>>instead of ints to convey position?
>>    
>>
>
>What do you do if that file gets deleted in the middle of a traversal?
>
So what?  It still tells you where to restart.  Strictly speaking, you 
would want to allow the filesystem to choose what it wants to return to 
indicate position.  For htree and reiserfs this would be a filename or 
its hash, for ext2 without htree this would be a byte offset.

>
>If I were able to design Unix over again, I'd state that if you don't lock a 
>directory before traversing it then it's your own fault if somebody changes 
>it under you, and I would have provided an interface to inform you about your 
>bad luck.  Strictly wishful thinking.  (There, it feels better now.)
>
We are designing Linux.  You know, Microsoft and Steve Jobs continue to 
design.  We should too.

Needless change should be avoided.  Failure to change when something is 
known to be broken leads to being inferior to those who do change.

Let's design something that does it right.  Or else SCO will be right in 
saying that Linux is just a Unix ripoff by people who couldn't do 
anything unless Unix had been written to tell them how to do it right.

-- 
Hans



  parent reply	other threads:[~2003-03-11 10:34 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-27 17:31 [Bug 417] New: htree much slower than regular ext3 Martin J. Bligh
2003-02-28  2:55 ` Daniel Phillips
2003-02-27 21:00   ` Andreas Dilger
2003-02-28  4:12     ` Daniel Phillips
2003-02-27 21:33       ` Martin J. Bligh
2003-03-13 21:04     ` [Ext2-devel] " Stephen C. Tweedie
2003-03-07 15:46 ` Alex Tomas
2003-03-08 17:38   ` Daniel Phillips
2003-03-07 23:27     ` Theodore Ts'o
2003-03-09 19:26       ` Alex Tomas
2003-03-09  7:08     ` Alex Tomas
2003-03-10 17:58       ` Daniel Phillips
2003-03-10 21:25       ` Theodore Ts'o
2003-03-11 21:57   ` Bill Davidsen
     [not found] ` <20030307214833.00a37e35.akpm@digeo.com>
     [not found]   ` <20030308010424.Z1373@schatzie.adilger.int>
2003-03-09 22:54     ` [Ext2-devel] " Daniel Phillips
2003-03-08 23:19       ` Andrew Morton
2003-03-09 23:10   ` Daniel Phillips
     [not found] ` <20030309184755.ACC80FCA8C@mx12.arcor-online.net>
     [not found]   ` <m3u1ecl5h8.fsf@lexa.home.net>
2003-03-10 20:45     ` [RFC] Improved inode number allocation for HTree Daniel Phillips
     [not found]       ` <3E6D1D25.5000004@namesys.com>
     [not found]         ` <20030311031216.8A31CEFD5F@mx12.arcor-online.net>
2003-03-11 10:45           ` Hans Reiser [this message]
2003-03-11 13:00             ` Helge Hafting
2003-03-11 13:41               ` Daniel Phillips
2003-03-11 17:16                 ` Andreas Dilger
2003-03-11 19:39                 ` Helge Hafting
2003-03-11 20:19                   ` Daniel Phillips
2003-03-11 21:25                 ` atomic kernel operations are very tricky to export to user space (was [RFC] Improved inode number allocation for HTree ) Hans Reiser
2003-03-11 23:49                   ` Jamie Lokier
2003-03-10 20:48     ` [RFC] Improved inode number allocation for HTree Daniel Phillips
2003-03-10 21:04       ` John Bradford
2003-03-10 21:28         ` Andreas Schwab
2003-03-10 21:50           ` Filesystem write priorities, (Was: Re: [RFC] Improved inode number allocation for HTree) John Bradford
2003-03-14 21:55             ` [Ext2-devel] " Stephen C. Tweedie
2003-03-10 21:33         ` [RFC] Improved inode number allocation for HTree Daniel Phillips
2003-03-10 21:47           ` [Ext2-devel] " Bryan O'Sullivan
2003-03-10 22:02             ` Matthew Wilcox
2003-03-11  8:47               ` Jakob Oestergaard
2003-03-11 11:27                 ` John Bradford
2003-03-14 21:57               ` Stephen C. Tweedie
2003-03-15  8:39                 ` jw schultz
     [not found] <20030311194014$426e@gated-at.bofh.it>
     [not found] ` <20030311194014$1a3c@gated-at.bofh.it>
     [not found]   ` <20030311194014$78c3@gated-at.bofh.it>
     [not found]     ` <20030311194014$5811@gated-at.bofh.it>
     [not found]       ` <20030311194014$49a6@gated-at.bofh.it>
2003-03-11 20:14         ` Pascal Schmidt

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=3E6DBE3B.8030007@namesys.com \
    --to=reiser@namesys.com \
    --cc=adilger@clusterfs.com \
    --cc=bzzz@tmi.comex.ru \
    --cc=chrisl@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@arcor.de \
    --cc=tytso@mit.edu \
    /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