On Tue, Dec 05, 2006 at 11:41:28AM -0500, Nikolai Joukov wrote:
As we promised on the linux-ext4 list on October 31, here is the patch
that adds secure deletion via a trash-bin functionality for ext4. It is a
compromise solution that combines secure deletion with the trash-bin
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody has a problem, and we don't take adding system calls lightly.
However, in this case we're talking
On Dec 05, 2006 15:55 -0800, Ulrich Drepper wrote:
I don't think an accuracy flag is useful at all. Programs don't want to
use fuzzy information. If you want a fast 'ls -l' then add a mode which
doesn't print the fields which are not provided. Don't provide outdated
information.
On Tue, Dec 05, 2006 at 03:44:31PM -0600, Rob Ross wrote:
The openg() really just does the lookup and permission checking). The
openfh() creates the file descriptor and starts that context if the
particular FS tracks that sort of thing.
...
Well you've caught me. I don't want to cache the
Hi,
This looks good to me, and I'm copying in Dave Wendy who have both
done previous work in this area for further comment. Provided we can get
this tested, I'd be happy to accept the patch in its current form.
Steve.
On Wed, 2006-12-06 at 00:34 -0500, J. Bruce Fields wrote:
From: J. Bruce
On Tue, Dec 05, 2006 at 09:55:16AM -0500, Trond Myklebust wrote:
The again statlite and
readdirplus really are the most sane bits of these proposals as they
fit nicely into the existing set of APIs. The filehandle idiocy on
the other hand is way of into crackpipe land.
...
Wendy Cheng wrote:
J. Bruce Fields wrote:
From: J. Bruce Fields [EMAIL PROTECTED]
From: Marc Eshel [EMAIL PROTECTED]
Add NFS lock support to GFS2. (Untested.)
Untested ? Trying to keep us busy ?
Sorry, forgot this is on external mailing lists
Nice piece of work ! This
Matthew Wilcox wrote:
On Tue, Dec 05, 2006 at 10:07:48AM +, Christoph Hellwig wrote:
The filehandle idiocy on the other hand is way of into crackpipe land.
Right, and it needs to be discarded. Of course, there was a real
problem that it addressed, so we need to come up with an acceptable
On Wed, 2006-12-06 at 13:22 +0100, Ragnar Kjørstad wrote:
On Tue, Dec 05, 2006 at 09:55:16AM -0500, Trond Myklebust wrote:
The again statlite and
readdirplus really are the most sane bits of these proposals as they
fit nicely into the existing set of APIs. The filehandle idiocy on
On Wed, 2006-12-06 at 03:28 -0700, Andreas Dilger wrote:
On Dec 05, 2006 10:23 -0500, Trond Myklebust wrote:
On Tue, 2006-12-05 at 03:26 -0700, Andreas Dilger wrote:
I think the barrier semantics are something that have just crept
into this discussion and is confusing the issue.
It
On Wed, 2006-12-06 at 11:01 +, Christoph Hellwig wrote:
Say you want to lookup a path /foo/bar/baz, then the access permission
is based on the following things:
- the credentials of the user. let's only take traditional uid/gid
for this example although credentials are much more
Christoph Hellwig wrote:
On Tue, Dec 05, 2006 at 03:44:31PM -0600, Rob Ross wrote:
The openg() really just does the lookup and permission checking). The
openfh() creates the file descriptor and starts that context if the
particular FS tracks that sort of thing.
...
Well you've caught me. I
Sage Weil wrote:
On Mon, 4 Dec 2006, Peter Staubach wrote:
I think that there are several points which are missing here.
First, readdirplus(), without any sort of caching, is going to be _very_
expensive, performance-wise, for _any_ size directory. You can see this
by instrumenting any NFS
David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody has a problem, and we don't take adding system calls lightly.
However, in this
On Wed, Dec 06, 2006 at 12:34:20AM -0500, J. Bruce Fields wrote:
+int gdlm_plock_callback(struct plock_op *op)
+{
+ struct file *file;
+ struct file_lock *fl;
+ int rv;
+
+ spin_lock(ops_lock);
+ if (!list_empty(op-list)) {
+ printk(KERN_INFO plock op on
Matthew Wilcox wrote:
On Wed, Dec 06, 2006 at 09:04:00AM -0600, Rob Ross wrote:
The openg() solution has the following advantages to what you propose.
First, it places the burden of the communication of the file handle on
the application process, not the file system. That means less work for
Ulrich Drepper wrote:
Andreas Dilger wrote:
Does this mean you are against the statlite() API entirely, or only
against
the document's use of the flag as a vague accuracy value instead of a
hard valid value?
I'm against fuzzy values. I've no problems with a bitmap specifying
that certain
Rob Ross wrote:
File size is definitely one of the more difficult of the parameters,
either because (a) it isn't stored in one place but is instead derived,
or (b) because a lock has to be obtained to guarantee consistency of the
returned value.
OK, and looking at the man page again, it is
On Wed, Dec 06, 2006 at 09:42:55AM -0800, Ulrich Drepper wrote:
I can't speak for everyone, but ls is the #1 consumer as far as I am
concerned.
So a syscall for ls alone?
I guess the code needs to be checked, but I would think that:
* ls
* find
* rm -r
* chown -R
* chmod -R
* rsync
*
Ragnar Kjørstad wrote:
I guess the code needs to be checked, but I would think that:
* ls
* find
* rm -r
* chown -R
* chmod -R
* rsync
* various backup software
* imap servers
Then somebody do the analysis. And please an analysis which takes into
account that some programs might need to be
On Wed, Dec 06, 2006 at 09:49:51AM -0600, David Teigland wrote:
The gfs side looks fine to me. Did you forget to call fl_notify from
gdlm_plock_callback() or am I missing something?
Yes, looks like we missed something, thanks. This code's an rfc (not
even tested), so don't apply it yet! What
On Wed, Dec 06, 2006 at 02:57:22PM -0500, J. Bruce Fields wrote:
On Wed, Dec 06, 2006 at 09:49:51AM -0600, David Teigland wrote:
The gfs side looks fine to me. Did you forget to call fl_notify from
gdlm_plock_callback() or am I missing something?
Yes, looks like we missed something,
On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody has a problem, and
On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote:
Permission checks are done on the path_to_handle(), so in reality
only root or CAP_SYS_ADMIN users can currently use the
open_by_handle interface because of this lack of checking. Given
that our current users of this interface need
On Wed, Dec 06, 2006 at 10:20:23AM -0600, Rob Ross wrote:
Matthew Wilcox wrote:
On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
David Chinner wrote:
Does anyone here know about the XFS libhandle API? This has been
around for years and it does _exactly_ what these proposed syscalls
David Chinner wrote:
On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody
On Wed, Dec 06, 2006 at 02:57:22PM -0500, J. Bruce Fields wrote:
On Wed, Dec 06, 2006 at 09:49:51AM -0600, David Teigland wrote:
The gfs side looks fine to me. Did you forget to call fl_notify from
gdlm_plock_callback() or am I missing something?
Yes, looks like we missed something,
On Wed, Dec 06, 2006 at 02:50:49PM -0600, Rob Ross wrote:
David Chinner wrote:
On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
David Chinner wrote:
Does anyone here know about the XFS libhandle API? This has been around
for
years and it does _exactly_ what these proposed syscalls
On Wed, Dec 06, 2006 at 01:50:24PM -0700, Matthew Wilcox wrote:
On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote:
Permission checks are done on the path_to_handle(), so in reality
only root or CAP_SYS_ADMIN users can currently use the
open_by_handle interface because of this
On Wed, Dec 06, 2006 at 03:42:31PM -0600, David Teigland wrote:
Oh yeah, that's painful, I knew it sounded too easy.
Yeah. Well, we could try to teach GFS2 to reliably cancel posix locks.
I think that may turn out to be necessary some day anyway.
Or we could look at why we're timing out and
On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote:
Considering that filesystems like GFS and OCFS allow clients DIRECT
ACCESS to the block device itself (which no amount of authentication
will fix, unless it is in the disks themselves), the risk of passing a
file handle around is
On 12/6/06, Rob Ross [EMAIL PROTECTED] wrote:
David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody has a problem, and we don't
On 12/5/06, Rob Ross [EMAIL PROTECTED] wrote:
I unfortunately don't have data to show exactly where the time was
spent, but it's a good guess that it is all the network traffic in the
open() case.
Is it hard to repeat the test and check what requests (and how much
time do they take) PVFS
On Wed, Dec 06, 2006 at 09:42:47AM -0600, Rob Ross wrote:
The fh_t is indeed a type of capability. fh_t, properly protected, could
be passed into user space and validated by the file system when
presented back to the file system.
Well, there's quite a lot of papers on how to implement
On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote:
While it could do that, I'd be interested to see how you'd construct
the handle such that it's immune to a malicious user tampering with it,
or saving it across a reboot, or constructing one from scratch.
If the server has to
On Wed, Dec 06, 2006 at 08:11:00PM +1100, David Chinner wrote:
They are defined but unused in 2.6.19, right? I can't see anywhere
in the 2.6.19 ext2/3/4/reiser trees that actually those flags,
including setting and retrieving them from disk. JFS i can see
sets, clears and retreives them, but
On Wed, Dec 06, 2006 at 07:56:19PM -0500, Josef Sipek wrote:
On Wed, Dec 06, 2006 at 08:11:00PM +1100, David Chinner wrote:
They are defined but unused in 2.6.19, right? I can't see anywhere
in the 2.6.19 ext2/3/4/reiser trees that actually those flags,
including setting and retrieving them
On Thu, Dec 07, 2006 at 12:44:27PM +1100, David Chinner wrote:
Maybe we should be using EAs for this sort of thing instead of flags
on the inode? If we keep adding inode flags for generic features
then we are going to force more than just XFS into inode format
changes eventually
Aren't
On Wed, Dec 06, 2006 at 09:35:30PM -0500, Josef Sipek wrote:
On Thu, Dec 07, 2006 at 12:44:27PM +1100, David Chinner wrote:
Maybe we should be using EAs for this sort of thing instead of flags
on the inode? If we keep adding inode flags for generic features
then we are going to force more
On Thu, 2006-12-07 at 13:49 +1100, David Chinner wrote:
On Wed, Dec 06, 2006 at 09:35:30PM -0500, Josef Sipek wrote:
On Thu, Dec 07, 2006 at 12:44:27PM +1100, David Chinner wrote:
Maybe we should be using EAs for this sort of thing instead of flags
on the inode? If we keep adding inode
On Wed, 2006-12-06 at 20:11 +1100, David Chinner wrote:
...
If all we need to add to XFS is support for those flags, then XFS
support would be trivial to add.
Oh, damn. I take that back. We're almost out of flag space in the on
disk inode - these two flags would use the last 2 flag bits so
On Tue, Dec 05, 2006 at 02:50:13PM -0500, Josef Sipek wrote:
On Tue, Dec 05, 2006 at 08:27:51PM +0100, Jan Engelhardt wrote:
On Dec 4 2006 07:30, Josef 'Jeff' Sipek wrote:
+#include union.h
+
+struct workqueue_struct *sioq;
+
+int __init init_sioq(void)
Although it's just me,
On Dec 6 2006 12:32, Josef Sipek wrote:
+int __init init_sioq(void)
Although it's just me, I'd prefer sioq_init(), sioq_exit(),
sioq_run(), etc. to go in hand with what most drivers use as naming
(i.e. modulename _ function).
That makes sense.
Hrm. Looking at the code, I noticed
On Dec 06, 2006 09:42 -0800, Ulrich Drepper wrote:
Rob Ross wrote:
File size is definitely one of the more difficult of the parameters,
either because (a) it isn't stored in one place but is instead derived,
or (b) because a lock has to be obtained to guarantee consistency of the
returned
Here is a rewrite of gdlm_plock_callback(). We still need to add the
lock cancel.
Marc.
int gdlm_plock_callback(struct plock_op *op)
{
struct file *file;
struct file_lock *fl;
int (*notify)(void *, void *, int) = NULL;
int rv;
spin_lock(ops_lock);
if
On Wed, Dec 06, 2006 at 07:14:58PM -0800, Nicholas Miell wrote:
On Thu, 2006-12-07 at 13:49 +1100, David Chinner wrote:
On Wed, Dec 06, 2006 at 09:35:30PM -0500, Josef Sipek wrote:
On Thu, Dec 07, 2006 at 12:44:27PM +1100, David Chinner wrote:
Maybe we should be using EAs for this sort
On Thu, 2006-12-07 at 12:44 +1100, David Chinner wrote:
Maybe we should be using EAs for this sort of thing instead of flags
on the inode? If we keep adding inode flags for generic features
then we are going to force more than just XFS into inode format
changes eventually
You do need to
On Tue, Dec 05, 2006 at 08:58:02PM -0800, Andrew Morton wrote:
On Mon, 4 Dec 2006 16:36:20 -0800 Valerie Henson [EMAIL PROTECTED] wrote:
Add relatime (relative atime) support. Relative atime only updates
the atime if the previous atime is older than the mtime or ctime.
Like noatime, but
On Wednesday 06 December 2006 05:58, Andrew Morton wrote:
On Mon, 4 Dec 2006 16:36:20 -0800 Valerie Henson
[EMAIL PROTECTED] wrote: Add relatime (relative atime)
support. Relative atime only updates the atime if the previous atime is
older than the mtime or ctime. Like noatime, but useful
if (inode-i_sb-s_flags MS_NOATIME)
return;
So that that one can be deleted.
Hi,
I would mostly expect the compiler to be relatively smart about this and
group a bunch of these tests together... so I rather see readable code
than optimized code for something the
50 matches
Mail list logo
