Mike Waychison wrote:
Tim Hockin wrote:
On Wed, Aug 25, 2004 at 04:25:24PM -0400, Rik van Riel wrote:
You can think of this as chroot on steroids.
Sounds like what you want is pretty much the namespace stuff
that has been in the kernel since the early 2.4 days.
No need to replicate VFS
OMG! It breaks tar and email!!! argument doesn't fly. Things break all
the time and are fixed. It's called progress.
Yes - we break things all the time. But we take notice, when we are
breaking things, of how long standing and deeply embedded they are.
The deeper the roots, the more respect
Mike Waychison wrote:
If I understand what Hans is looking to get done, he's asking for
someone to architect a system where any given process can be restricted
to seeing/accessing a subset of the namespace (in the sense of a tree
of directories/files). Eg: process Foo is allowed access to write
Matt Mackall wrote:
On Wed, Aug 25, 2004 at 05:42:21PM -0700, Nicholas Miell wrote:
On Wed, 2004-08-25 at 16:46, Wichert Akkerman wrote:
Previously Jeremy Allison wrote:
Multiple-data-stream files are something we should offer, definately (IMHO).
I don't care how we do it, but I
Matt Mackall wrote:
[...]
What it breaks is the concept of a file. In ways that are ill-defined,
not portable, hard to work with, and needlessly complex. Along the
way, it breaks every single application that ever thought it knew what
a file was.
Progress? No, this has been done before. Various
Andrew Morton wrote:
Hans Reiser [EMAIL PROTECTED] wrote:
I had not intended to respond to this because I have nothing positive to
say, but Andrew said I needed to respond and suggested I should copy
Linus.
Yes, but I didn't say flame Christoph and ignore the issues ;)
Oh;-)
There
Andrea Arcangeli wrote:
On Wed, Aug 25, 2004 at 11:00:00PM +0200, Christophe Saout wrote:
It should be completely forbidden to link into a meta-directory or out
of such a directory. [..]
agreed.
Yes, I don't think it was a good idea either. Probably someone should
I personally
Streams are quite ugly. However, if you decompose streams into all of
the little pieces that are needed to emulate them, the pieces are quite
nice.
For instance, inheriting stat data from a common parent is nice, and
inheritance is nice, and being able to cat dirname/pseudos/cat and get a
Rik van Riel wrote:
If your backup program dives into the file despite stat()
saying it's a file and you restore your backup, how are the
file is a file semantics preserved ?
Obviously this is something that needs to be sorted out at
the VFS layer.
It needs to be sorted out, whether it is sorted
Jamie Lokier wrote:
Nicholas Miell wrote:
Anything that currently stores a file's metadata in another file really
wants this right now. Things like image thumbnails, document summaries,
digital signatures, etc.
Additionally, all of those things you describe should be deleted if
the file is
Matthew Wilcox wrote:
That's a nice marketing talk. Get back to us when you have some technical
contribution to make.
www.namesys.com/download.html
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.
VFS is the common filesystem layer. The only reason you
Jeremy Allison wrote:
On Wed, Aug 25, 2004 at 12:53:28PM -0700, Hans Reiser wrote:
You ignored everything I said during the discussion of xattrs about how
there is no need to have attributes when you can just have files and
directories, and that xattrs reflected a complete ignorance of name
Chris Mason wrote:
This starts with exactly what Christoph described in writing a short
summary of how you want things to work today. Since we can't resist,
we'll also go ahead and rehash all the old flame wars over this, but try
to include some new ideas about where you want to see the reiser4
Linus Torvalds wrote:
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,
On Thu, Aug 26, 2004 at 11:53:30AM +0100, Jamie Lokier wrote:
Hans Reiser wrote:
being able to cat dirname/pseudos/cat and get a
concatenation of all of the files is nice, and being able to cat
dirname/pseudos/tar and get an archive of the directory is nice
Yes. Being able to cd
Previously Spam wrote:
How so? The whole idea is that the underlaying OS that handles the
copying should also know to copy everything, otherwise you can
implement everything into applications and just skip the whole
filesystem part.
UNIX doesn't have a copy
On Thu, 26 Aug 2004, Denis Vlasenko wrote:
I like cat a b. You can keep your progress.
cat a b does not preserve following file properties even on standard
UNIX filesystems: name,owner,group,permissions.
Losing permissions is one thing. Annoying, mostly.
However, actual losing file
Andrew Morton wrote:
No. All of the applications which you initially identified can be
implemented by putting the various bits of data into a single file and
getting applications to agree on the format of that file.
For example, some image file formats already support embedded metadata, do
Christer Weinigel wrote:
all applicatons that copy files will fail to copy the streams. So
no working cp command, no nautilus nor konqueror without changes to
the application.
No true. A lot of the fancy stuff depends on metadata which is merely
another view of the serialised contents in the
Am Donnerstag, den 26.08.2004, 16:04 +0100 schrieb Jamie Lokier:
Christophe Saout wrote:
What reiser4 can do, but the VFS can't is to insert or remove data in
the middle of a file. Adding this above the page cache would probably be
almost impossible (truncate seems already complicated
On Thu, Aug 26, 2004 at 02:43:34PM +0200, Olivier Galibert wrote:
On Thu, Aug 26, 2004 at 11:52:29AM +0100, Christoph Hellwig wrote:
Sure, no one stops you from playing around with new semantics. But please
don't add them to the linux kernel stable series until we have semantics we
a) want
On Thursday 26 August 2004 17:12, Rik van Riel wrote:
On Thu, 26 Aug 2004, Denis Vlasenko wrote:
I think Hans is not planning turning old file is a stream of bytes
into eight-stream octopus. One stream will remain as a 'main' one,
which contains actual data. Others will keep metadata,
Jamie Lokier writes:
Christophe Saout wrote:
What reiser4 can do, but the VFS can't is to insert or remove data in
the middle of a file. Adding this above the page cache would probably be
almost impossible (truncate seems already complicated enough).
That would be one of those
Christophe Saout wrote:
I think Hans' idea is (I don't know if it is a good idea nor if it is
doable, but at least it sounds interesting) to have special compound
files where you can do something like this:
cp text.txt test.compound/test.txt
cp image.jpg test.compound/image.jpg
And if
Am Donnerstag, den 26.08.2004, 17:37 +0200 schrieb Christoph Hellwig:
compression or encryption must sit below the pagecache to work nicely,
and this hint things that usually sit at the pagecache level. But let's
assume you have a valid use for different file_operations, why don't you
Jamie Lokier wrote:
However, as far as I know it's not accessible in a file-as-directory
form as yet. In my opinion that is the most natural form and it would
be very intuitive to use. I hope we can pick a useful semantics for
them, and also provide filesystem-independent plugins with GNU
On Thu, 26 Aug 2004, Jamie Lokier wrote:
Christophe Saout wrote:
And if you read test.compound (the main stream) you get a special format
that contains all the components. You can copy that single stream of
bytes to another (reiser4) fs and then access test.compound/test.txt
again.
On Thu, Aug 26, 2004 at 02:48:12PM +0100, Jamie Lokier wrote:
the current reiser4 semantics break that and as soon as you're having a
world-writeable (e.g. /tmp) dir on it and someone is doing an opendir
on it he's lost.
How does the current reiser4 semantics break that?
In a
Christophe Saout wrote:
I'm just thinking about something. While you can't cut bytes out of unix
iles a lot of filesystems can do this (holes). Most of them only on a
block boundary, reiser4 on a byte boundary. If the filesystems could
export this functionality using an enhanced API we could
Firstly, the core library _is_ used by different projects. That's the
commercial aim of reiser4: to be used by projects other than just as
Linux filesystem. For example it might be used by a database, or a
portable application which needs to store structured data in a flat
file (with random
Am Donnerstag, den 26.08.2004, 11:54 -0400 schrieb Rik van Riel:
And if you read test.compound (the main stream) you get a special format
that contains all the components. You can copy that single stream of
bytes to another (reiser4) fs and then access test.compound/test.txt
again.
On Thu, Aug 26, 2004 at 05:48:54PM +0200, Christophe Saout wrote:
I don't know, ask Hans. How could the VFS know it a filesystem wants to
do something specific with a file that is completely transparent to the
VFS?
The VFS shouldn't, that the whole point. That's why it allows the
Christoph Hellwig wrote:
There's bound to be some security issue, but I'm not sure what you're
getting at with /tmp. What sort of sort of security problem arises
with a world-writeable directory such as /tmp, that cannot arise with
the standard fs semantics?
Actually you are right on
Andrew Morton wrote:
No. All of the applications which you initially identified can be
implemented by putting the various bits of data into a single file and
getting applications to agree on the format of that file.
So in order to avoid breaking backup and file utilities, we'd instead
break
On Thu, Aug 26, 2004 at 06:04:42PM +0200, Christophe Saout wrote:
It should be a simple format. Something simliar to tar. The worst thing
that can happen is people start writing plugins for every existing
compound format out there. It should be the other way around, agree on a
simple compound
On Thu, Aug 26, 2004 at 05:06:38PM +0100, Jamie Lokier wrote:
Christoph Hellwig wrote:
There's bound to be some security issue, but I'm not sure what you're
getting at with /tmp. What sort of sort of security problem arises
with a world-writeable directory such as /tmp, that cannot
Am Donnerstag, den 26.08.2004, 18:06 +0200 schrieb Christoph Hellwig:
Again, your confusing upper and lower plugins. For things happening
below the pagecache you could register different address_space
operations which sometimes makes sense. But you want e.g. different
inode_operations for
Christoph Hellwig wrote:
Unfortunately, the problem is that reiser4 is the only filesystem
which is _technically capable_ of implementing that abstraction in a
practical way, apparently. (I'm not sure if this is really true.
reiser4's object model is not the same as paths and inodes, but
On Thu, Aug 26, 2004 at 05:19:11PM +0100, Jamie Lokier wrote:
Remember that reiser4 allows you to operate on little pieces of data,
glueing and rearranging them inside files (something like that).
No other filesystem has that capability, and it's a data model which
the fancy features (when
On Thu, Aug 26, 2004 at 06:14:19PM +0200, Christophe Saout wrote:
Ok, I see your point. aops. Sorry.
Looking at the code this could be done. The wrappers that dispatch the
operations are really small and call the plugin that is registered with
the inode of the mapping. Instead it could have
Hans Reiser wrote:
Andrew, we need to compete with WinFS and Dominic Giampaolo's filesystem
for Apple, and that means we need to put search engine and database
functionality into the filesystem. It takes 11 years of serious
Hans,
I'm very curious about your ideas on how to put search engine
On Thu, Aug 26, 2004 at 10:53:48AM +0300, Markus Törnqvist wrote:
On Thu, Aug 26, 2004 at 12:32:00AM -0500, Matt Mackall wrote:
What it breaks is the concept of a file. In ways that are ill-defined,
not portable, hard to work with, and needlessly complex. Along the
way, it breaks every
On Thu, 26 Aug 2004, Linus Torvalds wrote:
For example, you _could_ probably (but hey, maybe tar tries to strip
slashes off the end of filenames, so this might not work due to silly
reasons like that) back up a compound file with
tar cvf file.tar file file/
So you'd have both a file
Christoph Hellwig wrote:
How do you for example suggestion exporting your semantics over the
network if they're not done at the VFS level? How do you want some
clusterfilesystem support them or tmpfs?
by accesses to filename/metas.
That's the beauty of simplicity, not much is needed.
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 /foo/. does
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
On Thu, 26 Aug 2004, Linus Torvalds wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
[...]
| tar cvf file.tar file file/
I don't like it. Imagine this:
$ cat file/perm
040700 drwx--
$ cat file/perm/user/writable
1
$ cat file/perm/uid
0
Do that tar, and you lose the uid. This is an example, and has
Linus Torvalds wrote:
Well, you _could_ make it do a tar, but what's the point? That really
doesn't add any value as far as user space is concerned.
Think of it this way: if the directory and the default stream associated
with it aren't independent, then user space already has the
[reposted in thread]
On Thu, Aug 26, 2004 at 11:46:33AM -0700, Linus Torvalds wrote:
Note that we could try this out with existing filesystems with very
minimal changes:
- make directory bind mounts work on top of files (graft_tree())
- make open_namei() and friend _not_ do the
Am Donnerstag, den 26.08.2004, 14:59 -0400 schrieb Rik van Riel:
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 created with
the same name ?
I would say that the directory under a file is
On Thu, 2004-08-26 at 05:24, Hans Reiser wrote:
Andrew Morton wrote:
And describe the plugin system. Why does the filesystem need such a
thing (other filesystems get their features via `patch -p1')?
It takes 6 months or more to become competent to change a usual
filesystem.
Rik van Riel wrote:
What do we do with O_CREAT ?
Do we always allow both a directory and a file to be created with
the same name ?
I haven't analysed it thoroughly. I suspect it's fine as long as:
(1) O_CREAT creates something with file-like
attributes, meaning stat() says it's a
On Thu, Aug 26, 2004 at 03:26:55PM -0400, Lee Revell wrote:
OK, real world example. My roommate has an AKAI MPC-2000, a very
popular hardware sampler from the 90's. The disk format is known,there
are a few utilities to edit the disks on a PC and extract the PCM
samples, but there are no
Am Donnerstag, den 26.08.2004, 15:26 -0400 schrieb Lee Revell:
Well, in V4, you can easily compose a plugin from plugin methods of
other plugins, write a little piece of code with the one thing you want
different, and add it in. Disk format changes, no big deal, add a new
disk format
On Thu, Aug 26, 2004 at 09:28:41PM +0300, Denis Vlasenko wrote:
|
| Is it possible to sufficiently hide dirs inside files
| so that old tools will be unable to see them?
|
| I just checked:
|
| ls -d /foo does lstat64(/foo, ...)
| ls -d /foo/ does lstat64(/foo, ...)
| but
| ls -d /foo/.
Linus Torvalds wrote:
It is not the kernel which decides. The filesystem containing
/dev/hda/part1 opens the directory branch.
But that filesystem cannot know what the _other_ filesystem configurations
are. And that's what you'd have to have to mount.
At which point, userspace comes in.
Am Donnerstag, den 26.08.2004, 20:29 +0100 schrieb Jamie Lokier:
(1) O_CREAT creates something with file-like
attributes, meaning stat() says it's a regular file.
(2) File-like means it can be unlinked, linked and renamed, even if
someone has something inside it open. Nothing that
On Thu, 26 Aug 2004, Linus Torvalds wrote:
So /tmp/bash is _not_ two different things. It is _one_ entity, that
contains both a standard data stream (the file part) _and_ pointers to
other named streams (the directory part).
OK, that makes sense.
Hey, think of it as a wave-particle
On Thu, 2004-08-26 at 15:34, Christoph Hellwig wrote:
On Thu, Aug 26, 2004 at 03:26:55PM -0400, Lee Revell wrote:
OK, real world example. My roommate has an AKAI MPC-2000, a very
popular hardware sampler from the 90's. The disk format is known,there
are a few utilities to edit the disks
Am Donnerstag, den 26.08.2004, 15:44 -0400 schrieb Rik van Riel:
Hey, think of it as a wave-particle duality. Both modes exist at the
same time, and cannot be separated from each other. Which one you see
depends entirely on your experiment, ie how you open the file.
Guess I'm scared
On Thursday 26 August 2004 22:32, John Stoffel wrote:
Jamie Rik van Riel wrote:
And if an unaware application reads the compound file
and then writes it out again, does the filesystem
interpret the contents and create the other streams ?
Jamie Yes, exactly that. The streams are created
Joel Becker wrote:
On Thu, Aug 26, 2004 at 01:49:15AM -0700, Hans Reiser wrote:
Yes, this was part of the plan, tar file-directory plugins would be cute.
Question: Is cat /foo/bar/baz.tar.gz/metas the attribute
directory or a directory in the tarball named metas?
This needs to be
Christophe Saout writes:
Am Freitag, den 27.08.2004, 01:33 +0400 schrieb Nikita Danilov:
Wrong, plugin is called just below entry point from the VFS to the
file-system back-end. It can use reiser4 tree, or any storage layer it
wants. Or none at all: think about pseudo-files like
On Thursday 26 August 2004 20:17, Rik van Riel wrote:
On Thu, 26 Aug 2004, Jeremy Allison wrote:
Because without kernel support there is no way someone can
publish a new metadata type and have it automatically supported
by all application data files (ie. most apps ignore it, and only
apps
On Fri, Aug 27, 2004 at 02:03:36AM +0400, Nikita Danilov wrote:
What about fs/reiser4/plugin/node/ and fs/reiser4/plugin/disk_format/?
Of course you can implement another filesystem inside the plugins but
they wouldn't use fs/reiser4/*.c, so this would be rather stupid. Right?
[ 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 (we
Christophe Saout wrote:
Am Freitag, den 27.08.2004, 01:45 +0400 schrieb Nikita Danilov:
At least in reiser4 they don't have, or at least you can't access them.
They do.
ln -s foo bar; cd bar/metas shows me the content of foo/metas.
That's because lookup for bar performs symlink resolution.
On Thursday 26 August 2004 22:10, Rik van Riel wrote:
Do we really want to have a file paradigm that's different
from the other OSes out there ?
What happens when users want to transfer data from Linux
to another system ?
I think it depends on the transport being used: some transports could
Christophe Saout writes:
Am Freitag, den 27.08.2004, 01:45 +0400 schrieb Nikita Danilov:
At least in reiser4 they don't have, or at least you can't access them.
They do.
ln -s foo bar; cd bar/metas shows me the content of foo/metas.
That's because lookup for bar
Hello,
In the last couple of days one of my production servers started
rebooting due to a kernel panic. I believe this could be related to
something in the reiserfs file system that is causing the kernel to
panic. The panic also causes data corruption on some system files that
are heavily
Michael Halcrow wrote:
This is an issue that directly affects work I am doing in extended
cryptfs:
http://www.linuxsymposium.org/2004/view_abstract.php?content_key=55
http://halcrow.us/~mhalcrow/ols2004.pdf
http://halcrow.us/~mhalcrow/ols_cryptfs.sxi
Reiser4 has an encryption plugin that will
Am Freitag, den 27.08.2004, 02:21 +0400 schrieb Nikita Danilov:
BTW, I can do a cd metas/metas/metas/metas/plugin/metas... I don't think
this makes sense. :)
Why? foo/metas is a file system object just like foo. It has owner,
permission bits, so access to its meta-data should be
On Thursday 26 August 2004 23:05, David Lang wrote:
I also don't see why the VFS/Filesystem can't decide that (for example)
this tar.gz is so active that instead of storing it as a tar.gz and
providing a virtual directory of the contents that it instead stores the
directory of the contents
On Fri, Aug 27, 2004 at 12:30:19AM +0200, Felipe Alfaro Solana wrote:
On Thursday 26 August 2004 23:05, David Lang wrote:
I also don't see why the VFS/Filesystem can't decide that (for example)
this tar.gz is so active that instead of storing it as a tar.gz and
providing a virtual
On Thu, Aug 26, 2004 at 03:04:21PM -0700, Linus Torvalds wrote:
2) we would need to do something about locking, since mount trees in other
guys' namespaces are protected by semaphores of their own.
Ok, I'll admit that I don't know how to handle namespaces. These things
should just go
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... What do we do
On Thu, Aug 26, 2004 at 03:45:09PM -0700, Linus Torvalds wrote:
No, lookup would just return the dentry, but the dentry would already be
filled in with the mount-point information.
And you can do that with a simple vfs helper function, ie the filesystem
itself would just need to do
Linus Torvalds wrote:
For example, it's likely that most filesystems would _not_ allow linking
of a named stream anywhere else.
Why? It is just a file that inherits its stat data and is referenced by
a concatenation method of its parent directory. The link will also
inherit its stat data
On Fri, 27 Aug 2004, Felipe Alfaro Solana wrote:
On Thursday 26 August 2004 23:05, David Lang wrote:
I also don't see why the VFS/Filesystem can't decide that (for example)
this tar.gz is so active that instead of storing it as a tar.gz and
providing a virtual directory of the contents that it
i've tested reiser4 on a spare partition to see how well it would work
for me. unfortunately i hit some corruption problem. it seems perfectly
reproducable, so hardware error is very unlikely.
first some details on my system:
AMD Athlon(tm) XP 2400+
512 MB DDR-RAM (tested with memtest)
MSI
82 matches
Mail list logo
