On Fri, 28 Jul 2006, David Masover wrote:
>
> But what's wrong with people doing such experiments outside the kernel?
> AFAICS, "exotic, site-specific one" is not something that would be considered
> for inclusion.
Here's a few ground rules at least from my viewpoint:
- as long you call them
On Thu, 2 Mar 2006, Andrew Morton wrote:
>
> reiserfs-fix-unaligned-bitmap-usage.patch
I applied this one already, it seemed obvious.
(And then I've applied the ones you forwarded to me, of course).
Linus
On Tue, 12 Jul 2005, Jeff Mahoney wrote:
>
> scripts/Lindent fs/reiserfs/*.c include/linux/reiserfs_*.h
Ok, applied. You should check that you got the same results I did, and
feel free to send further cleanup patches. Sometimes "indent" does some
silly things.
Linus
On Tue, 12 Jul 2005, Jeff Mahoney wrote:
>
> This patch contains the result of running scripts/Lindent against
> fs/reiserfs/*.c and include/linux/reiserfs_*.h.
That can't be true. It isn't actually following the Lindent rules. It has
that braindamaged "put the type on a separate line" thing
On Thu, 2 Sep 2004, Alan Cox wrote:
>
> I asked our desktop people. They want something like inotify because
> dontify doesn't cut it.
Well, dnotify() really _is_ inotify(), since it does actually work on
inodes, not dentries.
I think what they are really complaining about is that dnotify() o
On Thu, 2 Sep 2004, Hans Reiser wrote:
> Linus Torvalds wrote:
> >
> >. Doing transactions on one file is
> >only the beginning - you'll find people who want transactions across file
> >boundaries etc.
>
> Yup, that's what reiser4 is aiming at a
On Wed, 1 Sep 2004, David Masover wrote:
>
> I think transactions should be done in kernel space. It's the only way
> to "enforce" them sanely.
Well, they clearly can't, since it depends on the filesystem. Also,
transactions have a tendency to be expensive, and people have a tendency
to ask
On Tue, 31 Aug 2004, Hans Reiser wrote:
>
> You are saying, 1-2% simpler and better, no biggie, why work so hard to
> get it?
>
> And we are saying, 1-2% simpler and better, times thousands of
> applications, wow! That's a lot!
But would thousands care? Seriously?
For example, you could mak
On Sat, 28 Aug 2004 [EMAIL PROTECTED] wrote:
>
> OK, forget getcwd(). What does lookup of .. do from that point? *Especially*
> for stuff you've got from regular files. That's the decision that needs to
> be made.
I think that will decide on whether we expose attributes through the
normal n
On Sat, 28 Aug 2004, Hans Reiser wrote:
>
> I object to openat().
Sound slike you object to O_XATTRS, not openat() itself.
Realize that openat() works independently of any special streams, it's
fundamentally a "look up name starting from this file" (rather than
"starting from root" or "star
On Thu, 26 Aug 2004 [EMAIL PROTECTED] wrote:
> >
> > It should be reasonably easy to create new ones on-the-fly, since we'd
> > have all the information (the parent vfsmount comes stated, and the
> > vfsmount we create would point to the same things that the "base" one
> > would).
>
> Erm... W
[ This is quite possibly just impossible and buggy, but here's my
implementation notes. You asked for them. ]
On Thu, 26 Aug 2004 [EMAIL PROTECTED] wrote:
>
> All right, let's see where that would take us.
>
> 1) we would need to find all vfsmounts over given dentry. Probably a cyclic
> list
On Thu, 26 Aug 2004, Rik van Riel wrote:
>
> Hmmm, I just straced "cp /bin/bash /tmp".
> One line stood out as a potential problem:
>
> open("/tmp/bash", O_WRONLY|O_CREAT|O_LARGEFILE, 0100755) = 4
>
> What do we do with O_CREAT ?
>
> Do we always allow both a directory and a file to be creat
On Thu, 26 Aug 2004, Rik van Riel wrote:
>
> So you'd have both a file and a directory that just happen
> to have the same name ? How would this work in the dcache?
There would be only one entry in the dcache. The lookup will select
whether it opens the file or the directory based on O_DIRECT
On Thu, 26 Aug 2004, Denis Vlasenko wrote:
>
> Is it possible to sufficiently hide "dirs inside files"
> so that old tools will be unable to see them?
Certainly possible.
> I just checked:
>
> ls -d /foo does lstat64("/foo", ...)
> ls -d /foo/ does lstat64("/foo", ...)
> but
> ls -d /f
On Wed, 25 Aug 2004, Christoph Hellwig wrote:
>
> Over the last at least five years we've taken as much as possible
> semantics out of the filesystems and into the VFS layer, thus having
> a separation between the semantical layer (VFS) and the low level
> filesystem. Your attributes are absoul
On Wed, 25 Aug 2004, Christoph Hellwig wrote:
>
> For one thing _I_ didn't decide about xattrs anyway. And I still
> haven't seen a design from you on -fsdevel how you try to solve the
> problems with files as directories.
Hey, files-as-directories are one of my pet things, so I have to side w
On Mon, 28 Jan 2002, Rik van Riel wrote:
>
> I'd be interested to know exactly how much overhead -rmap is
> causing for both page faults and fork (but I'm sure one of
> the regular benchmarkers can figure that one out while I fix
> the RSS limit stuff ;))
I doubt it is noticeable on page fault
On Mon, 28 Jan 2002, Josh MacDonald wrote:
>
> So, it would seem that the dcache and kmem_slab_cache memory allocator
> could benefit from a way to shrink the dcache in a less random way.
> Any thoughts?
The way I want to solve this problem generically is to basically get rid
of the special-purp
On Wed, 3 Oct 2001, Alexander Viro wrote:
>
> Ehh... Linus, both blkdev_get() and blkdev_open() should set ->i_blkbits.
Duh. I couldn't even _imagine_ that we'd be so stupid to have duplicated
that code twice instead of just having blkdev_open() call blkdev_get().
Thanks.
Linus
20 matches
Mail list logo
