above with an example? I don't really follow.
Thanks,
Mike Waychison
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-alone. But that's
more of a feature for the FIEMAP stuff.
I hadn't heard of FIEMAP, so I went back and read the thread from
April/May. It seems that this is a much better approach than
introducing a FIBMAP64.
What ever happened with this proposal?
Mike Waychison
-
To unsubscribe from this list
Jason Uhlenkott wrote:
On Fri, Oct 26, 2007 at 01:22:17 +0100, Alan Cox wrote:
On Thu, 25 Oct 2007 16:06:40 -0700
Mike Waychison [EMAIL PROTECTED] wrote:
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have
Jason Uhlenkott wrote:
On Fri, Oct 26, 2007 at 14:59:57 -0700, Mike Waychison wrote:
Jason Uhlenkott wrote:
Additionally, ext3_bmap() has this to say about it:
if (EXT3_I(inode)-i_state EXT3_STATE_JDATA) {
/*
* This is a REALLY heavyweight approach
of the locking in [4/6] fix_race_with_truncate.patch. Any help here
would greatly be appreciated.
The last patch, [6/6] drop_cap_sys_rawio_for_fibmap.patch, is of course, not to
be applied until any remaining issues are fixed :)
Thanks,
Mike Waychison
--
-
To unsubscribe from this list: send
Return an error if the user requests a negative logical block in a file.
Signed-off-by: Mike Waychison [EMAIL PROTECTED]
fs/ioctl.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.23/fs/ioctl.c
===
--- linux-2.6.23.orig
Move FIBMAP logic out of file_ioctl() in preparation for introducing FIBMAP64.
Signed-off-by: Mike Waychison [EMAIL PROTECTED]
fs/ioctl.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
Index: linux-2.6.23/fs/ioctl.c
Attempt to deal with races with truncate paths.
I'm not really sure on the locking here, but these seem to be taken by the
truncate path. BKL is left as some filesystem may(?) still require it.
Signed-off-by: Mike Waychison [EMAIL PROTECTED]
fs/ioctl.c |8
1 file changed, 8
Introduce FIBMAP64. This is the same as FIBMAP, but takes a u64.
This new routine requires filesystems to implement bmap64 if they want to
support 2^31 blocks in a logical file. We do this to give time for
filesystems to be properly audited.
Signed-off-by: Mike Waychison [EMAIL PROTECTED
Propagate an error (EFBIG) to userspace if the physical block is too large to
return in a 32bit int instead of truncating it.
Signed-off-by: Mike Waychison [EMAIL PROTECTED]
fs/ioctl.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
Index: linux-2.6.23/fs/ioctl.c
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have permission to see where their data is
landing on disk, and there really isn't a good reason to keep them from getting
at this information.
Signed-off-by: Mike
Alan Cox wrote:
On Thu, 25 Oct 2007 16:06:40 -0700
Mike Waychison [EMAIL PROTECTED] wrote:
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have permission to see where their data is
landing on disk
.., then the application can step out of the chroot using clone(2).
Note: using chdir in a vfsmount outside of your namespace works, however
you won't be able to walk off that vfsmount (to its parent or children).
Mike Waychison
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Hmm.. something is up with my quoting again..)
Ram wrote:
On Mon, 2005-01-31 at 23:02, Mike Waychison wrote:
Ram wrote:
On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ram wrote:
On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
OK, here comes the first draft of proposed semantics for subtree
sharing. What we want is being able to propagate events
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry for the bad quoting below:
[EMAIL PROTECTED] wrote:
On Fri, 28 Jan 2005, Mike Waychison wrote:
Al Viro wrote:
OK, here comes the first draft of proposed semantics for subtree
sharing. What we want is being able to propagate events
to
happen cross-namespace given a dirfd target is any worse than what is
already possible given a dirfd. If you don't want someone to play with
your namespace, don't give them a dirfd.
Thoughts?
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J. Bruce Fields wrote:
On Tue, Jan 25, 2005 at 04:47:04PM -0500, Mike Waychison wrote:
Although Al hasn't explicitly defined the semantics for mount
- --make-shared, I think the idea is that 'only' that mountpoint becomes
tagged as shared (becomes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
On Mon, Jan 17, 2005 at 03:11:18PM -0500, Mike Waychison wrote:
I don't think that solves the problem. B should receive copies (with
shared semantics if called for) of all mountpoints C1,..,Cn that are
children
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J. Bruce Fields wrote:
On Mon, Jan 17, 2005 at 02:30:27PM -0500, Mike Waychison wrote:
Well, if I understand it correctly:
(assuming /foo is vfsmount A)
$ mount --make-shared /foo
will make A-A
$ mount --bind /foo /foo/bar
will create
20 matches
Mail list logo
