Hans Reiser wrote:
I am just coming into the middle of this, so forgive me, but why are
you implementing this above the filesystem layer? It seems like
virtual files should be plugins that the filesystem calls while
resolving its lookups and finding links to the plugin. This means
that
Tigran Aivazian wrote:
b) it has serious (though unlikely to occur) race conditions wrt
filesystem's module unload and possibly with rename(2).
And perhaps with mount(2), which these days seems to do everything
rename(2) does and more?
-- Jamie
Miklos Szeredi wrote:
Problems:
- The filesystem will be littered with these loopback mounts. This
should be cleared upon unmount, and possibly when the dcache is
shrunk. There was a similar requirement for new autofs IIRC.
- Creation/removal of virtual files are not handled by
Stephen C. Tweedie wrote:
No. If we do posix_fallocate(), then there are only two choices:
we either pre-zero the file contents (in which case we are as well
doing it from user space), or we record in the inode that the file
isn't pre-zeroed and so optimise things.
3rd choice: preallocate
Jamie Lokier wrote:
3rd choice: preallocate space with room for interleaved indirection
blocks.
Sorry I take that thinko back. Too little sleep last night :-)
-- Jamie
Pavel Machek wrote:
So run with -noleaf, or compile it with -noleaf as the default. Those of
us who use AFS are used to that anyway.
Notice: they want that to go into 2.4.X. Recompiling all distros all
there is *not* option. But returning nlink==1 is option, and I like
it. (You should
by
+ * Jamie Lokier [EMAIL PROTECTED], 1999
*/
#include asm/uaccess.h
@@ -65,17 +67,22 @@
*/
static struct buffer_head * ext2_find_entry (struct inode * dir,
const char * const name, int namelen,
-struct
Manfred Spraul wrote:
Can you call F_REOPEN multiple times, or only once after
open(O_DEFEROPEN)?
If F_REOPEN should support multiple calls, then we need a filp specific
callback:
The FIFO code must send wake-ups when a filp is promoted from O_RDONLY
to O_RDWR, and it doesn't support
Matthew Kirkwood wrote:
Presumably this is so that the floppy driver can check that nobody
expects to read or write the disk while a format is in progress?
If so, I accept the need for O_NONE.
No, it's so fdformat can open /dev/fd0 before fd0 knows what floppy
format to use, and so it doesn't
Matthew Kirkwood wrote:
Why don't you just give O_NONE (value: 3) this behaviour?
Partially because I didn't want to break applications already
using this (IMHO, rather dubious) feature.
Mostly, though, because I wanted to leave the O_RDWR/etc.
permission checks in the open() path, to
Matthew Kirkwood wrote:
That being the case, I'd rather that O_NONE just went away. I
am unconvinced of its worth anyway.
Apparently it's used by fdformat and a few other small utils.
I don't think there would be many complaints if that were changed to
read _or_ write.
The two options
Ben Fennema wrote:
Is there some kind of future plan for a common 'fork' access methidology?
can I do something like inode-u.udf_i-streamdir = iget(stream dir ino num)
then, using ioctl calls on the file, access the files in streamdir?
(Keep using the kernel functionallity to access the
Ben Fennema wrote:
My first question is, CAN I actually use lookup and readdir on a file
(Is it ls being too smart by looking at the thing, deceiding its not a
directory, and giving up -- or is it the kernel?)
The kernel will more or less do what you ask, though Alex Viro's
concerns are
Richard B. Johnson wrote:
According to our Legal Department, to satisfy the GPL requirement
that we provide source to the end-user, they required that we supply a
"current" distribution of Linux if the end-user requests it.
There /is/ no single "current" distribution. *A* current
14 matches
Mail list logo
