Re: [PATCH 03/32] VFS/fsstack: cpp endif comments
On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote: diff --git a/include/linux/fs_stack.h b/include/linux/fs_stack.h index 6b52faf..28543ad 100644 --- a/include/linux/fs_stack.h +++ b/include/linux/fs_stack.h @@ -39,4 +39,4 @@ static inline void fsstack_copy_attr_times(struct inode *dest, dest-i_ctime = src-i_ctime; } -#endif /* _LINUX_FS_STACK_H */ +#endif /* not _LINUX_FS_STACK_H */ I hardly think this changes a thing, and it even goes against the de-facto standard of a lot of other files. Jan -- - 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
Re: [PATCH 05/32] Unionfs: do not use fsstack_copy_attr_all
On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote:
+/* copy a/m/ctime from the lower branch with the newest times */
+static inline void unionfs_copy_attr_times(struct inode *upper)
+{
+ /* XXX: should we notify_change on our upper inode? */
I do not think so. Inotifying should only happen when the user really
did something (e.g. touch, cp, whatever). When merely the newest time is
picked from a stack of files and applied to the user-visible dentry,
nothing should happen.
Jan
--
-
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
Re: [PATCH 08/32] Unionfs: cache-coherency - update inode times
On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote:
-static ssize_t unionfs_write(struct file * file, const char __user * buf,
+
+static ssize_t unionfs_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
int err = 0;
unionfs_read_lock(file-f_path.dentry-d_sb);
-
if ((err = unionfs_file_revalidate(file, 1)))
goto out;
err = do_sync_write(file, buf, count, ppos);
+ /* update our inode times upon a successful lower write */
+ if (err = 0)
+ unionfs_copy_attr_times(file-f_path.dentry-d_inode);
So, revisiting the question of inotifying, write() is indeed a case which
warrants notification (I think). Just was not sure what callers
unionfs_copy_attr_times can have.
@@ -245,6 +245,12 @@ static struct dentry *unionfs_lookup(struct inode *parent,
nd-dentry = path_save.dentry;
nd-mnt = path_save.mnt;
}
+ if (!IS_ERR(ret)) {
+ if (ret)
+ dentry = ret;
+ /* parent times may have changed */
+ unionfs_copy_attr_times(dentry-d_parent-d_inode);
+ }
On lookup? No inotify if you ask me...
@@ -675,8 +681,11 @@ out:
kfree(name);
+ if (!err)
+ unionfs_copy_attr_times(dentry-d_inode);
unionfs_unlock_dentry(dentry);
unionfs_read_unlock(dentry-d_sb);
+
return err;
}
Can't decide ;-)
@@ -1006,6 +1015,8 @@ static int unionfs_permission(struct inode *inode, int
mask,
break;
}
}
+ /* sync times which may have changed (asynchronously) below */
+ unionfs_copy_attr_times(inode);
out:
return err;
permission = readonly operation = no inotify
diff --git a/fs/unionfs/unlink.c b/fs/unionfs/unlink.c
index 822bffe..7ad19ec 100644
--- a/fs/unionfs/unlink.c
+++ b/fs/unionfs/unlink.c
@@ -41,6 +41,9 @@ static int unionfs_unlink_whiteout(struct inode *dir, struct
dentry *dentry)
dget(lower_dentry);
if (!(err = is_robranch_super(dentry-d_sb, bindex)))
err = vfs_unlink(lower_dir_dentry-d_inode, lower_dentry);
+ /* if vfs_unlink succeeded, update our inode's times */
+ if (!err)
+ unionfs_copy_attr_times(dentry-d_inode);
dput(lower_dentry);
fsstack_copy_attr_times(dir, lower_dir_dentry-d_inode);
unlock_dir(lower_dir_dentry);
unlink = write operation = inotify
Jan
--
-
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
Re: [PATCH 09/32] Unionfs: cache-coherency - dentries
On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote:
@@ -184,10 +183,92 @@ out:
}
/*
+ * Determine if the lower inode objects have changed from below the unionfs
+ * inode. Return 1 if changed, 0 otherwise.
+ */
+int is_newer_lower(const struct dentry *dentry)
Could use bool and true/false as return value.
-int __unionfs_d_revalidate_chain(struct dentry *dentry, struct nameidata *nd)
+int __unionfs_d_revalidate_chain(struct dentry *dentry, struct nameidata *nd,
+ int willwrite)
also looks like a bool (willwrite)
- if (!__unionfs_d_revalidate_chain(dentry, NULL)) {
+ if (!__unionfs_d_revalidate_chain(dentry, NULL, 0)) {
(Are there any callers with ,1?)
Jan
--
-
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
Re: [PATCH 12/32] Unionfs: documentation updates
On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote: + +While rebuilding Unionfs's objects, we also purge any page mappings and +truncate inode pages (see fs/Unionfs/dentry.c:purge_inode_data). This is to fs/unionfs/dentry.c +Unionfs maintains the following important invariant regarding mtime's, +ctime's, and atime's: the upper inode object's times are the max() of all of utimes, ctimes and atimes. +2. Lockdep (a debugging feature) isn't aware of stacking, and so it + incorrectly complains about locking problems. The problem boils down to + this: Lockdep considers all objects of a certain type to be in the same + class, for example, all inodes. Lockdep doesn't like to see a lock held + on two inodes within the same task, and warns that it could lead to a + deadlock. However, stackable file systems do precisely that: they lock + an upper object, and then a lower object, in a strict order to avoid + locking problems; in addition, Unionfs, as a fan-out file system, may + have to lock several lower inodes. We are currently looking into Lockdep + to see how to make it aware of stackable file systems. In the mean time, meantime @@ -86,5 +86,12 @@ command: # mount -t unionfs -o remount,incgen none MOUNTPOINT +Note that the older way of incrementing the generation number using an +ioctl, is no longer supported in Unionfs 2.0. Ioctls in general are not 2.1? Jan -- - 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
Re: [RFC 1/2] JBD: slab management support for large block(8k)
On Sun, 2 Sep 2007, Christoph Hellwig wrote: We are doing what you describe right now. So the current code is broken? Yes. How about getting rid of the slabs there and use kmalloc? Kmalloc in mm (and therfore hopefully 2.6.24) will convert kmallocs PAGE_SIZE to page allocator calls. Not sure what to do about the 1k and 2k requests though. - 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
Re: [2/4] 2.6.23-rc5: known regressions
Hi all, Here is a list of some known regressions in 2.6.23-rc5. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Adrian Bunk9 Linus Torvalds 6 Andi Kleen 5 Hugh Dickins 5 Andrew Morton 4 Al Viro3 Alan Stern 3 Alexey Starikovskiy3 Cornelia Huck 3 Jens Axboe 3 Stephen Hemminger 3 Tejun Heo 3 Unclassified Subject : console is messed up after resume from s2ram or switching to console from X References : http://lkml.org/lkml/2007/8/4/6 Last known good : ? Submitter : Jeff Chua [EMAIL PROTECTED] Caused-By : ? Handled-By : H. Peter Anvin [EMAIL PROTECTED] Antonino A. Daplas [EMAIL PROTECTED] Workaround : s2ram --force --acpi_sleep 1 --vbe_mode Status : problem is being debugged Subject : konqueror suddenly vanishing, konqueror: Fatal IO error: client killed References : http://lkml.org/lkml/2007/7/22/86 Last known good : ? Submitter : Markus [EMAIL PROTECTED] Caused-By : ? Handled-By : Ingo Molnar [EMAIL PROTECTED] Status : problem is being debugged CPUFREQ Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not References : http://lkml.org/lkml/2007/7/27/298 http://lkml.org/lkml/2007/7/29/371 Last known good : ? Submitter : dth [EMAIL PROTECTED] Caused-By : Len Brown [EMAIL PROTECTED] commit f79e3185dd0f8650022518d7624c876d8929061b Handled-By : Len Brown [EMAIL PROTECTED] Status : problem is being debugged FS Subject : NFSv3 server error in LOOKUP after READDIRPLUS Call References : http://bugzilla.kernel.org/show_bug.cgi?id=8966 Last known good : ? Submitter : Peter Kovar [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Status : unknown Subject : [NFSD OOPS] 2.6.23-rc1-git10 References : http://lkml.org/lkml/2007/8/2/462 Last known good : ? Submitter : Andrew Clayton [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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
[1/2] 2.6.23-rc5: known regressions with patches
Hi all, Here is a list of some known regressions in 2.6.23-rc5 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Adrian Bunk9 Linus Torvalds 6 Andi Kleen 5 Hugh Dickins 5 Andrew Morton 4 Al Viro3 Alan Stern 3 Alexey Starikovskiy3 Cornelia Huck 3 Jens Axboe 3 Stephen Hemminger 3 Tejun Heo 3 Unclassified Subject : 8250 claims non existing device blocking IO port References : http://lkml.org/lkml/2007/8/18/20 Last known good : ? Submitter : Andrey Borzenkov [EMAIL PROTECTED] Caused-By : ? Handled-By : Bjorn Helgaas [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/8/21/291 Status : patch available Subject : Oops while modprobing phy fixed module References : http://lkml.org/lkml/2007/7/14/63 Last known good : ? Submitter : Gabriel C [EMAIL PROTECTED] Caused-By : ? Handled-By : Satyam Sharma [EMAIL PROTECTED] Vitaly Bordug [EMAIL PROTECTED] Patch1 : http://lkml.org/lkml/2007/7/18/506 Status : patch available FS Subject : NFSv4 client OOPS References : http://lkml.org/lkml/2007/8/28/207 Last known good : ? Submitter : Harry Edmon [EMAIL PROTECTED] Caused-By : ? Handled-By : Trond Myklebust [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/8/28/204 Status : patch available Subject : autofs mounts mysteriously disappeared References : http://lkml.org/lkml/2007/8/29/222 http://lkml.org/lkml/2007/8/30/234 Last known good : 2.6.22 Submitter : Hua Zhong [EMAIL PROTECTED] Caused-By : ? Handled-By : Trond Myklebust [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/8/31/189 Status : patch available IDE Subject : linux-2.6.23-rc4 ppc build failure References : http://lkml.org/lkml/2007/8/29/154 Last known good : ? Submitter : Bret Towe [EMAIL PROTECTED] Caused-By : ? Handled-By : Tony Breeds [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/8/31/1 Status : patch was suggested Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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
Re: [2/4] 2.6.23-rc5: known regressions
Michal Piotrowski wrote: Unclassified Subject : console is messed up after resume from s2ram or switching to console from X References : http://lkml.org/lkml/2007/8/4/6 Last known good : ? Submitter : Jeff Chua [EMAIL PROTECTED] Caused-By : ? Handled-By : H. Peter Anvin [EMAIL PROTECTED] Antonino A. Daplas [EMAIL PROTECTED] Workaround : s2ram --force --acpi_sleep 1 --vbe_mode Status : problem is being debugged I'm inclined to write this one off as general STR weirdness. The problem is reproducible on 2.6.22 if CONFIG_FB is enabled (even if not *used*!), and there is a working workaround that is required on a lot of machines. This is suboptimal, of course, but it seems to require a pretty deep investigation into the intricacies of this particular platform. -hpa - 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
Re: [2/4] 2.6.23-rc5: known regressions
On 9/3/07, Michal Piotrowski [EMAIL PROTECTED] wrote: Subject : console is messed up after resume from s2ram or switching to console from X References : http://lkml.org/lkml/2007/8/4/6 Last known good : ? Submitter : Jeff Chua [EMAIL PROTECTED] Caused-By : ? Handled-By : H. Peter Anvin [EMAIL PROTECTED] Antonino A. Daplas [EMAIL PROTECTED] Workaround : s2ram --force --acpi_sleep 1 --vbe_mode Status : problem is being debugged Michal, Can you please close this case. I'm using the workaround and satisfied with it. Thanks, Jeff. - 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
Re: [2/4] 2.6.23-rc5: known regressions
On Mon, 03 Sep 2007 11:48:00 +0100 H. Peter Anvin [EMAIL PROTECTED] wrote: Michal Piotrowski wrote: Unclassified Subject : console is messed up after resume from s2ram or switching to console from X References : http://lkml.org/lkml/2007/8/4/6 Last known good : ? Submitter : Jeff Chua [EMAIL PROTECTED] Caused-By : ? Handled-By : H. Peter Anvin [EMAIL PROTECTED] Antonino A. Daplas [EMAIL PROTECTED] Workaround : s2ram --force --acpi_sleep 1 --vbe_mode Status : problem is being debugged I'm inclined to write this one off as general STR weirdness. Both suspend-to-ram and suspend-to-disk are broken on this Vaio. Running 2.6.23-rc4. suspend-to-RAM: a) sometimes hangs during suspend b) frequently hangs during resume c) occasionally acts weird after resume. system requires repeated keypresses to make forward progress. d) on those occasions where resume-from-RAM _does_ work, it takes much longer to resume than it used to. suspend-to-disk: a) always hangs when netconsole-over-e100 is enabled (might have been a 2.6.21-2.6.22 regression). b) usually hangs during suspend Apart from suspend-to-disk's a), all of the above are post-2.6.21 regressions. - 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
Re: [2/4] 2.6.23-rc5: known regressions
On Mon, 3 Sep 2007 20:36:32 +0800 Jeff Chua [EMAIL PROTECTED] wrote: On 9/3/07, Michal Piotrowski [EMAIL PROTECTED] wrote: Subject : console is messed up after resume from s2ram or switching to console from X References : http://lkml.org/lkml/2007/8/4/6 Last known good : ? Submitter : Jeff Chua [EMAIL PROTECTED] Caused-By : ? Handled-By : H. Peter Anvin [EMAIL PROTECTED] Antonino A. Daplas [EMAIL PROTECTED] Workaround : s2ram --force --acpi_sleep 1 --vbe_mode Status : problem is being debugged Michal, Can you please close this case. I'm using the workaround and satisfied with it. 2.6.21 was OK, and 2.6.23-rc2 needed a manual workaround? That's a regression. - 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
Re: [2/4] 2.6.23-rc5: known regressions
On Mon, 3 Sep 2007 05:46:02 -0700 Andrew Morton [EMAIL PROTECTED] wrote: Apart from suspend-to-disk's a), all of the above are post-2.6.21 regressions. I meant: post-2.6.22 regressions. - 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
Re: [2/4] 2.6.23-rc5: known regressions
Andrew Morton wrote: On Mon, 3 Sep 2007 20:36:32 +0800 Jeff Chua [EMAIL PROTECTED] wrote: On 9/3/07, Michal Piotrowski [EMAIL PROTECTED] wrote: Subject : console is messed up after resume from s2ram or switching to console from X References : http://lkml.org/lkml/2007/8/4/6 Last known good : ? Submitter : Jeff Chua [EMAIL PROTECTED] Caused-By : ? Handled-By : H. Peter Anvin [EMAIL PROTECTED] Antonino A. Daplas [EMAIL PROTECTED] Workaround : s2ram --force --acpi_sleep 1 --vbe_mode Status : problem is being debugged Michal, Can you please close this case. I'm using the workaround and satisfied with it. 2.6.21 was OK, and 2.6.23-rc2 needed a manual workaround? That's a regression. Yes, it is. 2.6.21 was OK, but only within a narrow and ill-characterized set of conditions (framebuffer not compiled into the kernel, in particular.) It appears to me that the interaction between STR and video on this system is extremely fragile, to the point that any minor perturbations in the state can break it, and that that is the real underlying problem here. -hpa - 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
Re: [RFC 1/2] JBD: slab management support for large block(8k)
On Mon, Sep 03, 2007 at 12:55:04AM -0700, Christoph Lameter wrote: On Sun, 2 Sep 2007, Christoph Hellwig wrote: We are doing what you describe right now. So the current code is broken? Yes. How about getting rid of the slabs there and use kmalloc? Kmalloc in mm (and therfore hopefully 2.6.24) will convert kmallocs PAGE_SIZE to page allocator calls. Not sure what to do about the 1k and 2k requests though. The problem is that we must never use kmalloc pages, so we always need to request a page or more for these. Better to use get_free_page directly, that's how I fixed it in XFS a while ago. - 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
Re: [PATCH 12/32] Unionfs: documentation updates
On Mon, Sep 03, 2007 at 08:59:02AM +0200, Jan Engelhardt wrote: On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote: + +While rebuilding Unionfs's objects, we also purge any page mappings and +truncate inode pages (see fs/Unionfs/dentry.c:purge_inode_data). This is to fs/unionfs/dentry.c +Unionfs maintains the following important invariant regarding mtime's, +ctime's, and atime's: the upper inode object's times are the max() of all of utimes, ctimes and atimes. +2. Lockdep (a debugging feature) isn't aware of stacking, and so it + incorrectly complains about locking problems. The problem boils down to + this: Lockdep considers all objects of a certain type to be in the same + class, for example, all inodes. Lockdep doesn't like to see a lock held + on two inodes within the same task, and warns that it could lead to a + deadlock. However, stackable file systems do precisely that: they lock + an upper object, and then a lower object, in a strict order to avoid + locking problems; in addition, Unionfs, as a fan-out file system, may + have to lock several lower inodes. We are currently looking into Lockdep + to see how to make it aware of stackable file systems. In the mean time, meantime @@ -86,5 +86,12 @@ command: # mount -t unionfs -o remount,incgen none MOUNTPOINT +Note that the older way of incrementing the generation number using an +ioctl, is no longer supported in Unionfs 2.0. Ioctls in general are not 2.1? Thanks. Jeff. -- Penguin : Linux version 2.4.20-46.9.legacysmp on an i386 machine (2778.72 BogoMips). - 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
Re: [PATCH 09/32] Unionfs: cache-coherency - dentries
On Mon, Sep 03, 2007 at 08:52:17AM +0200, Jan Engelhardt wrote:
On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote:
@@ -184,10 +183,92 @@ out:
}
/*
+ * Determine if the lower inode objects have changed from below the unionfs
+ * inode. Return 1 if changed, 0 otherwise.
+ */
+int is_newer_lower(const struct dentry *dentry)
Could use bool and true/false as return value.
I remember that way back when there was a discussion about the bool type.
What how did that end? Is bool preferred?
-int __unionfs_d_revalidate_chain(struct dentry *dentry, struct nameidata
*nd)
+int __unionfs_d_revalidate_chain(struct dentry *dentry, struct nameidata
*nd,
+ int willwrite)
also looks like a bool (willwrite)
Right.
-if (!__unionfs_d_revalidate_chain(dentry, NULL)) {
+if (!__unionfs_d_revalidate_chain(dentry, NULL, 0)) {
(Are there any callers with ,1?)
Indirectly yes. There are callers that pass a value they get. Very large
majority is 0.
Jeff.
--
Bad pun of the week: The formula 1 control computer suffered from a race
condition
-
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
Re: [PATCH 09/32] Unionfs: cache-coherency - dentries
On Sep 3 2007 10:08, Josef 'Jeff' Sipek wrote: +int is_newer_lower(const struct dentry *dentry) Could use bool and true/false as return value. I remember that way back when there was a discussion about the bool type. What how did that end? Is bool preferred? Well if there were objections, it would not be in the tree. Jan -- - 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
Re: [PATCH 01/32] VFS: export release_open_intent symbol
On Sun, 2 Sep 2007, Josef 'Jeff' Sipek wrote: diff --git a/fs/namei.c b/fs/namei.c index a83160a..b2b7c8e 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -374,6 +374,7 @@ void release_open_intent(struct nameidata *nd) else fput(nd-intent.open.file); } +EXPORT_SYMBOL(release_open_intent); Hmm, why is this being pushed into mainline? This also looks like an -mm only patch to me, there are no modular users of release_open_intent() in mainline, and the next patch doesn't add one either. - 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
Re: [GIT PULL -mm] Unionfs/fsstack/eCryptfs updates/cleanups/fixes
In message [EMAIL PROTECTED], Al Boldi writes:
Josef 'Jeff' Sipek wrote:
The following is a series of patches related to Unionfs, which include
three small VFS/fsstack patches and one eCryptfs patch; the rest are
Unionfs patches. The patches here represent several months of work and
testing under various conditions, especially low-memory, SMP, and
preemption situations with an assortment of lower systems: ext2/3/4, xfs,
reiserfs, nfs, jffs2, ramfs, tmpfs, cramfs, and squashfs.
To increase test-usage, it may be critical to always backport at least to
the latest stable release, like 2.6.22.
Thanks!
--
Al
Al, we have back-ports of the latest Unionfs to 2.6.{22,21,20,19,18,9}, all
in http://unionfs.filesystems.org/. Before we release any change, we test
it on all back-ports as well as the latest -rc/-mm code base (takes over 24
hours straight to get through all of our regressions :-)
So we'd be happy to submit those patches to the latest stable kernel. But,
are you talking about VFS/ecryptfs patches (which are in the stable kernel),
or are you talking about Unionfs (which is not)?
Thanks,
Erez.
-
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
Re: [PATCH 01/32] VFS: export release_open_intent symbol
On Mon, Sep 03, 2007 at 09:59:15PM +0530, Satyam Sharma wrote: On Sun, 2 Sep 2007, Josef 'Jeff' Sipek wrote: diff --git a/fs/namei.c b/fs/namei.c index a83160a..b2b7c8e 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -374,6 +374,7 @@ void release_open_intent(struct nameidata *nd) else fput(nd-intent.open.file); } +EXPORT_SYMBOL(release_open_intent); Hmm, why is this being pushed into mainline? This also looks like an -mm only patch to me, there are no modular users of release_open_intent() in mainline, and the next patch doesn't add one either. Err...a thinko. Good catch. Josef 'Jeff' Sipek. -- I abhor a system designed for the user, if that word is a coded pejorative meaning stupid and unsophisticated. - Ken Thompson - 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
[RFC] System calls for online defrag
Hello,
I've finally got to writing up some proposal how could look system calls
allowing for online filesystem defragmentation and generally moving file
blocks around for improving performance. Comments are welcome.
Honza
int sys_movedata(int datafd, int spacefd, loff_t from, size_t len)
The call takes blocks used to carry data starting at offset @from of length
@len in @spacefd and places them instead of corresponding blocks in @datafd.
Data is copied from @datafd to newly spliced data blocks. If @spacefd contains
a hole in the specified interval, a hole is created also in @datafd in the
corresponding place. A data block from @spacefd and also replace a hole in
@datafd - zeros are copied to such data block. @from and @len should be
multiples of filesystem block size (otherwise EINVAL is returned). Data blocks
from @datafd in the interval are released, a hole is created in @spacefd. The
call returns either 0 (success) or an error code.
Another possibility would be to just replace data blocks without any copying
of data (that would have to be done by the caller to before calling
sys_movedata()). The problem here is how to avoid data loss if someone writes
to the file after userspace has copied the data and before sys_movedata() is
called.
ssize_t sys_allocate(int fd, int mode, loff_t goal, ssize_t len)
Allocate new space to file @fd at offset defined by file position. Both file
offset and @len should be a multiple of filesystem block size. The whole
interval must not contain any allocated blocks. If the interval extends past
EOF, the file size is changed accordingly. @mode defines a way the filesystem
will search for blocks. @mode is a bitwise OR of the following flags:
ALLOC_FIXED_START - allocation must start at @goal; if not specified, @goal
is just a hint where to start an allocation
ALLOC_FIXED_LEN - allocate exactly space for @len; if not specified, upto
@len bytes may be allocated.
ALLOC_CONTINGUOUS - allocation must be one continguous run of blocks
If the allocation succeeds, number of allocated bytes is returned. Otherwise
an error code is returned.
The following syscall may be also useful - although I'm not completely
convinced this is the right way to go. But on the other hand, disk optimizer
should have a way to find out about free space so that he can decide what and
where is beneficial to move.
int sys_get_free_blocks(const char *fs, loff_t start, loff_t end, int count,
struct alloc_extent *space)
Get a description of free space on a filesystem between @start and @end (in
bytes, should be blocksize aligned). @fs is a path where the filesystem is
mounted (I guess it's better than dev_t, isn't it?). @space is a pointer to an
array of 'struct alloc_extent'. In each struct alloc_extent is stored
description of one extent of free space. Upto @count extents are stored.
struct alloc_extent {
loff_t start;
size_t len;
};
Function returns a number of extents stored. Note that the result of the
function is unreliable as the space can be already allocated by the time system
call returns.
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
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
Re: [GIT PULL -mm] Unionfs/fsstack/eCryptfs updates/cleanups/fixes
Erez Zadok wrote:
Al, we have back-ports of the latest Unionfs to 2.6.{22,21,20,19,18,9},
all in http://unionfs.filesystems.org/. Before we release any change, we
test it on all back-ports as well as the latest -rc/-mm code base (takes
over 24 hours straight to get through all of our regressions :-)
I am impressed, thanks!
It's probably a good idea to always point these backports out, whenever
submitting patches against -mm. Otherwise, people might forget.
So we'd be happy to submit those patches to the latest stable kernel.
But, are you talking about VFS/ecryptfs patches (which are in the stable
kernel), or are you talking about Unionfs (which is not)?
I'm talking about Unionfs, which seems like a rather critical feature to
miss-out on. BTW, did you ever get that oops-on-umount worked out?
Thanks!
--
Al
-
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
Re: [GIT PULL -mm] Unionfs/fsstack/eCryptfs updates/cleanups/fixes
In message [EMAIL PROTECTED], Al Boldi writes:
Erez Zadok wrote:
Al, we have back-ports of the latest Unionfs to 2.6.{22,21,20,19,18,9},
all in http://unionfs.filesystems.org/. Before we release any change, we
test it on all back-ports as well as the latest -rc/-mm code base (takes
over 24 hours straight to get through all of our regressions :-)
I am impressed, thanks!
You're welcome.
It's probably a good idea to always point these backports out, whenever
submitting patches against -mm. Otherwise, people might forget.
Good idea.
So we'd be happy to submit those patches to the latest stable kernel.
But, are you talking about VFS/ecryptfs patches (which are in the stable
kernel), or are you talking about Unionfs (which is not)?
I'm talking about Unionfs, which seems like a rather critical feature to
miss-out on.
Hmmm, we'll have to discuss this among the unionfs developers first.
BTW, did you ever get that oops-on-umount worked out?
Which bug? Is that something anyone submitted to our
https://bugzilla.filesystems.org? I don't recall such a bug in a while, so
if it got fixed, it must've been a while back. If it's still there and
reproducible, please let me know asap so I can work on it.
It is possible that the bug is in the -mm code. That's why we just posted
the long series of Unionfs patches: those patches represent more than four
months of intense hardening and testing. Some of the bugs we've fixed had
to do with improper refcounting (esp. mnt refcounting, which, if not
perfect, either causes an EBUSY on unmount or an oops on unmount :-)
Thanks!
--
Al
Erez.
-
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
Re: [RFC 1/2] JBD: slab management support for large block(8k)
On Mon, Sep 03, 2007 at 12:31:49PM -0700, Christoph Lameter wrote: So you'd be fine with replacing the allocs with get_free_pages(GFP_xxx, get_order(size)) ? Yes. And rip out all that code related to setting up the slabs. I plan to add WARN_ONs to bio_add_page and friends to detect further usage of slab pages if there is any. - 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
[PATCH] 9p: attach-per-user
The 9P2000 protocol requires the authentication and permission checks to be
done in the file server. For that reason every user that accesses the file
server tree has to authenticate and attach to the server separately.
Multiple users can share the same connection to the server.
Currently v9fs does a single attach and executes all I/O operations as a
single user. This makes using v9fs in multiuser environment unsafe as it
depends on the client doing the permission checking.
This patch improves the 9P2000 support by allowing every user to attach
separately. The patch defines three modes of access (new mount option
'access'):
- attach-per-user (access=user)
If a user tries to access a file served by v9fs for the first time, v9fs
sends an attach command to the server (Tattach) specifying the user. If
the attach succeeds, the user can access the v9fs tree.
As there is no uname-uid (string-integer) mapping yet, this mode works
only with the 9P2000.u dialect.
- allow only one user to access the tree (access=uid)
Only the user with uid can access the v9fs tree. Other users that attempt
to access it will get EPERM error.
- do all operations as a single user (access=any)
V9fs does a single attach and all operations are done as a single user.
If this mode is selected, the v9fs behavior is identical with the current
one.
The patch also renames uid and gid options to dfltuid and dfltgid. The new
names describe better the values they set.
Signed-off-by: Latchesar Ionkov [EMAIL PROTECTED]
---
commit 836f166ce5578b084c1cd75807e29474586bab61
tree c7e1eb631c3e6b0f1cd773ae7884379776c2857d
parent 3ec910913c8c743cbe4cd9cdde17df26a75d02ec
author Latchesar Ionkov [EMAIL PROTECTED](none) Mon, 03 Sep 2007 14:09:29
-0600
committer Latchesar Ionkov [EMAIL PROTECTED](none) Mon, 03 Sep 2007 14:09:29
-0600
fs/9p/fid.c | 157 +--
fs/9p/v9fs.c| 87 +++---
fs/9p/v9fs.h| 27 +++-
fs/9p/vfs_inode.c | 52
include/net/9p/9p.h |7 +-
include/net/9p/client.h |5 +
net/9p/client.c | 10 ++-
net/9p/conv.c | 32 --
8 files changed, 278 insertions(+), 99 deletions(-)
diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index 15e05a1..b16b14b 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -1,6 +1,7 @@
/*
* V9FS FID Management
*
+ * Copyright (C) 2007 by Latchesar Ionkov [EMAIL PROTECTED]
* Copyright (C) 2005, 2006 by Eric Van Hensbergen [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify
@@ -34,9 +35,9 @@
#include fid.h
/**
- * v9fs_fid_insert - add a fid to a dentry
+ * v9fs_fid_add - add a fid to a dentry
+ * @dentry: dentry that the fid is being added to
* @fid: fid to add
- * @dentry: dentry that it is being added to
*
*/
@@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid *fid)
}
/**
- * v9fs_fid_lookup - return a locked fid from a dentry
+ * v9fs_fid_find - retrieve a fid that belongs to the specified uid
* @dentry: dentry to look for fid in
- *
- * find a fid in the dentry, obtain its semaphore and return a reference to it.
- * code calling lookup is responsible for releasing lock
- *
- * TODO: only match fids that have the same uid as current user
+ * @uid: return fid that belongs to the specified user
+ * @any: if non-zero, return any fid associated with the dentry
*
*/
-struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
+static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
{
struct v9fs_dentry *dent;
- struct p9_fid *fid;
-
- P9_DPRINTK(P9_DEBUG_VFS, dentry: %s (%p)\n, dentry-d_iname, dentry);
- dent = dentry-d_fsdata;
- if (dent)
- fid = list_entry(dent-fidlist.next, struct p9_fid, dlist);
- else
- fid = ERR_PTR(-EBADF);
+ struct p9_fid *fid, *ret;
+
+ P9_DPRINTK(P9_DEBUG_VFS, dentry: %s (%p) uid %d any %d\n,
+ dentry-d_iname, dentry, uid, any);
+ dent = (struct v9fs_dentry *) dentry-d_fsdata;
+ ret = NULL;
+ if (dent) {
+ spin_lock(dent-lock);
+ list_for_each_entry(fid, dent-fidlist, dlist) {
+ if (any || fid-uid == uid) {
+ ret = fid;
+ break;
+ }
+ }
+ spin_unlock(dent-lock);
+ }
- P9_DPRINTK(P9_DEBUG_VFS, fid: %p\n, fid);
- return fid;
+ return ret;
}
/**
- * v9fs_fid_clone - lookup the fid for a dentry, clone a private copy and
- * release it
+ * v9fs_fid_lookup - lookup for a fid, try to walk if not found
* @dentry: dentry to look for fid in
*
- * find a fid in the dentry and then clone to a new private fid
- *
- * TODO: only match fids that have the same uid as current user
- *
+ * Look for a fid in the specified
[PATCH 1/1] Unionfs: cache-coherency - dentries
From: Erez Zadok [EMAIL PROTECTED]
Utility functions to check if lower dentries/inodes are newer than upper
ones, and purging cached data if lower objects are newer. Also passed flag
to our d_revalidate_chain, to tell it if the caller may be writing data or
just reading it.
[jsipek: changed purge_inode_data to take a struct inode]
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
---
fs/unionfs/commonfops.c |2 +-
fs/unionfs/dentry.c | 143 ++-
fs/unionfs/inode.c | 24 +---
fs/unionfs/rename.c |4 +-
fs/unionfs/super.c |2 +-
fs/unionfs/union.h |5 +-
fs/unionfs/unlink.c | 12 +++-
fs/unionfs/xattr.c |8 +-
8 files changed, 164 insertions(+), 36 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 28cb4e9..0dc7492 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -287,7 +287,7 @@ int unionfs_file_revalidate(struct file *file, int
willwrite)
* but not unhashed dentries.
*/
if (!d_deleted(dentry)
- !__unionfs_d_revalidate_chain(dentry, NULL)) {
+ !__unionfs_d_revalidate_chain(dentry, NULL, willwrite)) {
err = -ESTALE;
goto out_nofree;
}
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 4a3c479..d937329 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -23,19 +23,18 @@
* Assume that dentry's info node is locked.
* Assume that parent(s) are all valid already, but
* the child may not yet be valid.
- * Returns 1 if valid, 0 otherwise.
+ * Returns true if valid, false otherwise.
*/
-static int __unionfs_d_revalidate_one(struct dentry *dentry,
+static bool __unionfs_d_revalidate_one(struct dentry *dentry,
struct nameidata *nd)
{
- int valid = 1; /* default is valid (1); invalid is 0. */
+ bool valid = true; /* default is valid */
struct dentry *lower_dentry;
int bindex, bstart, bend;
int sbgen, dgen;
int positive = 0;
int locked = 0;
int interpose_flag;
-
struct nameidata lowernd; /* TODO: be gentler to the stack */
if (nd)
@@ -128,7 +127,7 @@ static int __unionfs_d_revalidate_one(struct dentry *dentry,
interpose_flag);
if (result) {
if (IS_ERR(result)) {
- valid = 0;
+ valid = false;
goto out;
}
/*
@@ -142,7 +141,7 @@ static int __unionfs_d_revalidate_one(struct dentry *dentry,
if (positive UNIONFS_I(dentry-d_inode)-stale) {
make_bad_inode(dentry-d_inode);
d_drop(dentry);
- valid = 0;
+ valid = false;
goto out;
}
goto out;
@@ -158,12 +157,12 @@ static int __unionfs_d_revalidate_one(struct dentry
*dentry,
|| !lower_dentry-d_op-d_revalidate)
continue;
if (!lower_dentry-d_op-d_revalidate(lower_dentry,
- lowernd))
- valid = 0;
+ lowernd))
+ valid = false;
}
if (!dentry-d_inode)
- valid = 0;
+ valid = false;
if (valid) {
/*
@@ -184,12 +183,94 @@ out:
}
/*
+ * Determine if the lower inode objects have changed from below the unionfs
+ * inode. Return 1 if changed, 0 otherwise.
+ */
+bool is_newer_lower(const struct dentry *dentry)
+{
+ int bindex;
+ struct inode *inode;
+ struct inode *lower_inode;
+
+ /* ignore if we're called on semi-initialized dentries/inodes */
+ if (!dentry || !UNIONFS_D(dentry))
+ return false;
+ inode = dentry-d_inode;
+ if (!inode || !UNIONFS_I(inode) ||
+ ibstart(inode) 0 || ibend(inode) 0)
+ return false;
+
+ for (bindex = ibstart(inode); bindex = ibend(inode); bindex++) {
+ lower_inode = unionfs_lower_inode_idx(inode, bindex);
+ if (!lower_inode)
+ continue;
+ /*
+* We may want to apply other tests to determine if the
+* lower inode's data has changed, but checking for changed
+* ctime and mtime on the lower inode should be enough.
+*/
+ if (timespec_compare(inode-i_mtime,
+lower_inode-i_mtime) 0) {
+ printk(unionfs: new lower inode mtime
+ (bindex=%d, name=%s)\n,
