lkml.org 
[lkml]   [2004]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] [Request for inclusion] Filesystem in Userspace
From
Date

> > There are already "strange" filesystems in the kernel which cannot
> > really get rid of dirty data. I'm thinking of tmpfs and ramfs.
> > Neither of them are prone to deadlock, though both of them are "worse
> > off" than a userspace filesystem, in the sense that they have not even
> > the remotest chance of getting rid of the dirty data.
> >
> > Of course, implementing this is probably not trivial. But I don't see
> > it as a theoretical problem as Linus does.
> >
> > Is there something which I'm missing here?
>
> But they KNOW that they won't be able to get rid of the dirty data. But
> fuse does not.

Why not? I can set bdi->memory_backed to 1 just like ramfs, implement
my own writeback thread, and voila, no deadlock.

Of course I believe, that it's probably easier to tweak the page cache
to teach it that fuse pages _can_ be written back, but not reliably
like a disk filesystem. And there's the small problem of limiting the
number of writable pages allocated to FUSE.

Miklos
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.460 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site