Hi!
> I'm pleased to announce third release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
How is this different from raid0/1 over nbd? Or raid0/1 o
On Fri, 21 Sep 2007 16:51:25 -0500
Michael Halcrow <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 19, 2007 at 10:38:50PM -0700, Andrew Morton wrote:
> > > + virt = kmap(page_for_lower);
> > > + rc = ecryptfs_write_lower(ecryptfs_inode, virt, offset, size);
> > > + kunmap(page_for_lower);
> > > + return
On Wed, Sep 19, 2007 at 10:38:50PM -0700, Andrew Morton wrote:
> > + virt = kmap(page_for_lower);
> > + rc = ecryptfs_write_lower(ecryptfs_inode, virt, offset, size);
> > + kunmap(page_for_lower);
> > + return rc;
> > +}
>
> argh, kmap. http://lkml.org/lkml/2007/9/15/55
Here is a patch t
> > What I'm saying is that read and write are _no_more_ related to the
> > file than fstat. Read/write operate on inode data, fstat operates on
> > inode metadata.
>
> The read and write operations are DEFINITELY related to the file descriptor
> because of f_pos. Each process opening the same f
> On Sep 21, 2007 14:23 +0200, Miklos Szeredi wrote:
> > @@ -1212,7 +1212,8 @@ struct inode_operations {
> > - int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
> > + int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *,
> > + struct fil
On Thu, 20 Sep 2007, Christoph Lameter wrote:
> On Thu, 20 Sep 2007, David Chinner wrote:
> > > Disagree, the mmap side is not a little change.
> >
> > That's not in the filesystem, though. ;)
>
> And its really only a minimal change for some function to loop over all
> 4k pages and elsewhere in
On Sep 21, 2007 14:23 +0200, Miklos Szeredi wrote:
> Add a new attribute flag ATTR_OPEN, with the meaning: "truncation was
> initiated by open() due to the O_TRUNC flag".
>
> This way filesystems wanting to implement truncation within their
> ->open() method can ignore such truncate requests.
Th
On Sep 21, 2007 16:59 +0200, Miklos Szeredi wrote:
> What I'm saying is that read and write are _no_more_ related to the
> file than fstat. Read/write operate on inode data, fstat operates on
> inode metadata.
The read and write operations are DEFINITELY related to the file descriptor
because of
On Sep 21, 2007 14:23 +0200, Miklos Szeredi wrote:
> @@ -1214,10 +1214,12 @@ struct inode_operations {
> + int (*setxattr) (struct dentry *, const char *,const void *,size_t,int,
> + struct file *);
> + ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t
On Sep 21, 2007 14:23 +0200, Miklos Szeredi wrote:
> @@ -1212,7 +1212,8 @@ struct inode_operations {
> - int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
> + int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *,
> + struct file *f
> On Fri, Sep 21, 2007 at 04:48:58PM +0200, Miklos Szeredi wrote:
> > Ah, OK. Well, that's what fuse would do with the above change. So
> > you are basically saying, the change is OK, but we want proper
> > unprivileged mounts first.
>
> Yes, that and that it should be a mount flag, not a file_s
> On Fri, Sep 21, 2007 at 10:32:31AM -0400, Trond Myklebust wrote:
> > On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
> >
> > > > ftruncate is a special case due to O_TRUNC.
> > >
> > > No, it's special, because it does not do permission checking, while
> > > truncate() does.
> >
> > S
On Fri, Sep 21, 2007 at 04:48:58PM +0200, Miklos Szeredi wrote:
> Ah, OK. Well, that's what fuse would do with the above change. So
> you are basically saying, the change is OK, but we want proper
> unprivileged mounts first.
Yes, that and that it should be a mount flag, not a file_system_type
f
> On Fri, Sep 21, 2007 at 03:18:33PM +0200, Miklos Szeredi wrote:
> > > That's something that shouldn't be solved in the filesystem, but rather
> > > through exact semantics of unprivilegued mounts. Given that an
> > > unprivilegued implies ignoring the device files we can easily allow
> > > users
> > > ftruncate is a special case due to O_TRUNC.
> >
> > No, it's special, because it does not do permission checking, while
> > truncate() does.
>
> So why not just add file->f_op->ftruncate() and file->f_op->fstat()?
Sure, we could add those.
I'm not sure it's worth adding new file operation
On Fri, Sep 21, 2007 at 10:32:31AM -0400, Trond Myklebust wrote:
> On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
>
> > > ftruncate is a special case due to O_TRUNC.
> >
> > No, it's special, because it does not do permission checking, while
> > truncate() does.
>
> So why not just add
On Fri, Sep 21, 2007 at 03:18:33PM +0200, Miklos Szeredi wrote:
> > That's something that shouldn't be solved in the filesystem, but rather
> > through exact semantics of unprivilegued mounts. Given that an
> > unprivilegued implies ignoring the device files we can easily allow
> > users to create
On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
> > ftruncate is a special case due to O_TRUNC.
>
> No, it's special, because it does not do permission checking, while
> truncate() does.
So why not just add file->f_op->ftruncate() and file->f_op->fstat()?
Most filesystems can trivially
> > Take this example: I've loopback mounted an UML disk image using fuse
> > (no privileges required), and want to create some device nodes. I
> > can't yet boot the UML because the device node is missing from the
> > image. So what should I do. Currently I have to manipulate the
> > mounted im
> > I don't think it's silly. Read/write get passed the file descriptor,
> > and it makes a lot of sense, if the filesystem has stateful opens.
> >
> > Similarly for any fs operation that gets a file descriptor, it makes
> > sense to pass the relevant open file down into the filesystem.
>
> read
On Fri, Sep 21, 2007 at 03:10:26PM +0200, Miklos Szeredi wrote:
> Take this example: I've loopback mounted an UML disk image using fuse
> (no privileges required), and want to create some device nodes. I
> can't yet boot the UML because the device node is missing from the
> image. So what should
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Add a new filesystem flag, that results in the VFS not checking if the
> > current process has enough privileges to do an mknod().
> >
> > This is needed on filesystems, where an unprivileged user may be able
> > to create a device node, withou
On Fri, Sep 21, 2007 at 03:00:06PM +0200, Miklos Szeredi wrote:
> I don't think it's silly. Read/write get passed the file descriptor,
> and it makes a lot of sense, if the filesystem has stateful opens.
>
> Similarly for any fs operation that gets a file descriptor, it makes
> sense to pass the
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Add a new attribute flag ATTR_OPEN, with the meaning: "truncation was
> > initiated by open() due to the O_TRUNC flag".
> >
> > This way filesystems wanting to implement truncation within their
> > ->open() method can ignore such truncate reque
> On Fri, Sep 21, 2007 at 02:23:46PM +0200, Miklos Szeredi wrote:
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Pass the open file into the filesystem's *xattr() methods.
> >
> > This is needed to be able to correctly implement open-unlink-f*xattr
> > semantics, without having to resort to
On Fri, Sep 21, 2007 at 02:23:48PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add a new filesystem flag, that results in the VFS not checking if the
> current process has enough privileges to do an mknod().
>
> This is needed on filesystems, where an unprivileged
On Fri, Sep 21, 2007 at 02:23:47PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add a new attribute flag ATTR_OPEN, with the meaning: "truncation was
> initiated by open() due to the O_TRUNC flag".
>
> This way filesystems wanting to implement truncation within thei
On Fri, Sep 21, 2007 at 02:23:46PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Pass the open file into the filesystem's *xattr() methods.
>
> This is needed to be able to correctly implement open-unlink-f*xattr
> semantics, without having to resort to "silly-renami
From: Miklos Szeredi <[EMAIL PROTECTED]>
Pass the open file into the filesystem's ->getattr() method for
fstat().
This is needed to be able to correctly implement open-unlink-fstat
semantics in some filesystem such as sshfs, without having to resort
to "silly-renaming".
Do this by adding a 'stru
From: Miklos Szeredi <[EMAIL PROTECTED]>
Pass the open file into the filesystem's ->setattr() method for
fchmod, fchown and some of the utimes variants.
This is needed to be able to correctly implement open-unlink-fsetattr
semantics in some filesystem such as sshfs, without having to resort
to "s
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add a new attribute flag ATTR_OPEN, with the meaning: "truncation was
initiated by open() due to the O_TRUNC flag".
This way filesystems wanting to implement truncation within their
->open() method can ignore such truncate requests.
This is a quick & dirt
From: Miklos Szeredi <[EMAIL PROTECTED]>
Pass the open file into the filesystem's *xattr() methods.
This is needed to be able to correctly implement open-unlink-f*xattr
semantics, without having to resort to "silly-renaming".
Do this by adding a 'struct file *' parameter to i_op->*xattr(). For
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add a new filesystem flag, that results in the VFS not checking if the
current process has enough privileges to do an mknod().
This is needed on filesystems, where an unprivileged user may be able
to create a device node, without causing security problems.
Hi,
Here's a bunch a VFS interface changes that are needed to implement
some FUSE features.
The biggest part is patches 1-3, which pass the open file to the
filesystem for syscalls passed an file descriptor, such as fstat(),
fchmod(), etc... These patches touch a lot of filesystems, but
otherwis
On Thu, Sep 20, 2007 at 05:18:40PM -0700, Andrew Morton wrote:
> On Wed, 19 Sep 2007 18:30:25 +0200
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > + /*
> > +* It's not a directory. Life is a little more complicated.
> > +*/
> > + struct dentry *ta
35 matches
Mail list logo
