headers
Mingming Cao | 1 Dec 2007 02:22
Picon
Favicon

Re: [EXT4 set 6][PATCH 1/1]Export jbd stats through procfs

On Fri, 2007-11-30 at 17:08 -0600, Eric Sandeen wrote:
> Mingming Cao wrote:
> > [PATCH] jbd2 stats through procfs
> > 
> > The patch below updates the jbd stats patch to 2.6.20/jbd2.
> > The initial patch was posted by Alex Tomas in December 2005
> > (http://marc.info/?l=linux-ext4&m=113538565128617&w=2).
> > It provides statistics via procfs such as transaction lifetime and size.
> > 
> > [ This probably should be rewritten to use debugfs?   -- Ted]
> > 
> > Signed-off-by: Johann Lombardi <johann.lombardi <at> bull.net>
> 
> I've started going through this one to clean it up to the point where it
> can go forward.  It's been sitting at the top of the unstable portion of
> the patch queue for long enough, I think :)
> 
Thanks!

> I've converted the msecs to jiffies until the user boundary, changed the
> union #defines as suggested by Andrew, and various other little issues etc.
> 
> Remaining to do is a generic time-difference calculator (instead of
> jbd2_time_diff), and looking into whether it should be made a config
> option; I tend to think it should, but it's fairly well sprinkled
> through the code, so I'll see how well that works.
> 
> Also did we ever decided if this should go to debugfs?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Mackall | 3 Dec 2007 05:50
Favicon

Re: [1/4] dst: Distributed storage documentation.

On Thu, Nov 29, 2007 at 03:53:23PM +0300, Evgeniy Polyakov wrote:
> 
> Distributed storage documentation.
> 
> Algorithms used in the system, userspace interfaces
> (sysfs dirs and files), design and implementation details
> are described here.

Can you give us a summary of how this differs from using device mapper
with NBD?

--

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Nick Piggin | 3 Dec 2007 07:46
Picon

[rfc][patch 1/2] inotify: fix race

Hmm, thinking I'd better just take a hammer to this inotify problem
despite the fact I cannot confirm the root cause of the warning messages.
Possibilities include the race being fixed here, and races in the
debug code itself.

--

There is a race between setting an inode's children's "parent watched" flag
when placing the first watch on a parent, and instantiating new children of
that parent: a child could miss having its flags set by set_dentry_child_flags,
but then inotify_d_instantiate might still see !inotify_inode_watched.

The solution is to set_dentry_child_flags after adding the watch. Locking is
taken care of, because both set_dentry_child_flags and inotify_d_instantiate
hold dcache_lock and child->d_locks.

Signed-off-by: Nick Piggin <npiggin <at> suse.de>
---
Index: linux-2.6/fs/inotify.c
===================================================================
--- linux-2.6.orig/fs/inotify.c
+++ linux-2.6/fs/inotify.c
 <at>  <at>  -627,6 +627,7  <at>  <at>  s32 inotify_add_watch(struct inotify_han
 		      struct inode *inode, u32 mask)
 {
 	int ret = 0;
+	int newly_watched;

 	/* don't allow invalid bits: we don't want flags set */
 	mask &= IN_ALL_EVENTS | IN_ONESHOT;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick Piggin | 3 Dec 2007 07:48
Picon

[rfc][patch 2/2] inotify: remove debug code


The inotify debugging code is supposed to verify that the
DCACHE_INOTIFY_PARENT_WATCHED scalability optimisation does not result in
notifications getting lost nor extra needless locking generated.

Unfortunately there are also some races in the debugging code. And it isn't
very good at finding problems anyway. So remove it for now.

Signed-off-by: Nick Piggin <npiggin <at> suse.de>
---
Index: linux-2.6/fs/dcache.c
===================================================================
--- linux-2.6.orig/fs/dcache.c
+++ linux-2.6/fs/dcache.c
 <at>  <at>  -1408,9 +1408,6  <at>  <at>  void d_delete(struct dentry * dentry)
 	if (atomic_read(&dentry->d_count) == 1) {
 		dentry_iput(dentry);
 		fsnotify_nameremove(dentry, isdir);
-
-		/* remove this and other inotify debug checks after 2.6.18 */
-		dentry->d_flags &= ~DCACHE_INOTIFY_PARENT_WATCHED;
 		return;
 	}

Index: linux-2.6/fs/inotify.c
===================================================================
--- linux-2.6.orig/fs/inotify.c
+++ linux-2.6/fs/inotify.c
 <at>  <at>  -168,20 +168,14  <at>  <at>  static void set_dentry_child_flags(struc
 		struct dentry *child;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Evgeniy Polyakov | 3 Dec 2007 12:16
Picon
Picon

Re: [1/4] dst: Distributed storage documentation.

Hi Matt.

On Sun, Dec 02, 2007 at 10:50:59PM -0600, Matt Mackall (mpm <at> selenic.com) wrote:
> > Distributed storage documentation.
> > 
> > Algorithms used in the system, userspace interfaces
> > (sysfs dirs and files), design and implementation details
> > are described here.
> 
> Can you give us a summary of how this differs from using device mapper
> with NBD?

From the higher point ov view it does not, but it operates quite differently:
it has async processing of the requests, thus not blocking, it has
different protocol with smaller overhead, supports strong checksums, has
in-kernel export server, which supports simple security attributes (i.e.
allow to connect, to read or write). It uses smaller amount of memory
(zero additional allocations in the common path for linear mapping,
not including network allocations, it uses smaller amount of additional
allocations for mirroring case).
DST supports failure recovery in case of dropped connection (core will
reconnect to the remote node when it is ready), thus it is possible to
turn off and on remote nodes without special administration steps. DST
has simple autoconfiguration at the startup time (support checksums and
storage size autonegotiation). It is possible to turn one of the mirror
nodes off and use it as a offline backup, since dst mirror node stores
data at the end of the storage, so it can be mounted locally.

--

-- 
	Evgeniy Polyakov
(Continue reading)

Permalink | Reply | 0 comments |
headers
Subrata Modak | 3 Dec 2007 12:29
Picon

[ANNOUNCE] The Linux Test Project has been Released for NOVEMBER 2007

Dear All,

The Linux Test Project test suite has been released for the month of
NOVEMBER 2007. The latest version of the test-suite contains 3000+
tests for the Linux OS and can be found at http://ltp.sourceforge.net/.
Latest happenings in LTP can also be found at:
http://ltp.sourceforge.net/wiki/,
http://ltp.sourceforge.net/wikiArchives.php, and,
IRC: irc.freenode.org #ltp.

Our web site also contains other information such as:
- A Linux test tools matrix
- Technical papers
- How To's on Linux testing
- Code coverage analysis tool.

Release Highlights:

* Several Network Test Cases has been updated to be run on different
subnet configuration,
* Updated lot of Test Cases to enable them run on NFS,
* Addition of posix_fadvise, fadvise64, madvise03, sendfile64 &
sendfile04 Test Cases to LTP
* Existing code in LTP-Kdump has been enhanced to test dump on Network
and different partitions, added IA64 support to KDUMP and lots of
changes in KDUMP scripts for error correction and improvement,
* Option to generate more parsible output in HTML format has been added,
* Option to automatically mail back LTP reports has been added,
* OpenHPI 2.10.1 has been integrated to LTP,
* Updated several Test Cases for suiting to proper GPLv2 License,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Mason | 3 Dec 2007 15:00
Picon
Favicon

Reminder: Last day for submissions to the Storage and Filesystem Workshop.

Hello everyone,

The deadline for position statements to the Linux Storage and
Filesystem Workshop is here.  Submitting a position statement
is an easy way for you to tell the organizers that you would like to
attend, and which topics you are most interesting in.

You can find all the details about the workshop here:

http://www.usenix.org/events/lsf08/

The Linux Storage and Filesystem Workshop is a small, tightly focused,
by-invitation workshop. It is intended to bring together developers and
researchers interested in implementing improvements in the Linux
filesystem and storage subsystems that can find their way into the
mainline kernel and into Linux distributions in the 1–2 year timeframe.
The workshop will be two days and will be separated into storage and
filesystem tracks, with some combined plenary sessions.

The workshop will be held Feb 25 and 26 in San Jose.

-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Felix Blyakher | 3 Dec 2007 18:00
Picon
Favicon

Re: Leak in nlmsvc_testlock for async GETFL case


On Nov 29, 2007, at 12:46 PM, Oleg Drokin wrote:

> Hello!
>
>    Per our discussion, I am resending this patch that fixes a leak  
> in nlmsvc_testlock.
>    It is addition to another leak fixing patch you already have.
>    Without the patch, there is a leakage of nlmblock structure  
> refcount that holds a
>    reference nlmfile structure, that holds a reference to struct  
> file, when async GETFL
>    is used (-EINPROGRESS return from file_ops->lock()), and also in  
> some error cases.
>
> Bye,
>     Oleg
> <nlmblock-leak_fix-1.diff>
>

 >  <at>  <at>  -502,15 +509,19  <at>  <at> 
 > 			}
 > 			else {
 > 				nlmsvc_unlink_block(block);
 > -				return nlm_granted;
 > +				ret = nlm_granted;
 > +                                goto out;
 > 			}

Do we really need to release block with 'goto out' here?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oleg Drokin | 3 Dec 2007 18:49
Picon

Re: Leak in nlmsvc_testlock for async GETFL case

Hello!

On Dec 3, 2007, at 12:00 PM, Felix Blyakher wrote:
>>   Per our discussion, I am resending this patch that fixes a leak  
>> in nlmsvc_testlock.
>>   It is addition to another leak fixing patch you already have.
>>   Without the patch, there is a leakage of nlmblock structure  
>> refcount that holds a
>>   reference nlmfile structure, that holds a reference to struct  
>> file, when async GETFL
>>   is used (-EINPROGRESS return from file_ops->lock()), and also in  
>> some error cases.
> >  <at>  <at>  -502,15 +509,19  <at>  <at> 
> > 			}
> > 			else {
> > 				nlmsvc_unlink_block(block);
> > -				return nlm_granted;
> > +				ret = nlm_granted;
> > +                                goto out;
> > 			}
>
> Do we really need to release block with 'goto out' here?

Yes, absolutely.

> nlmsvc_unlink_block() is doing it internally in the following
> call chain:
...
> And on a last reference 'block' will be freed in nlmsvc_free_block.
> Are you sure we have an extra reference here and won't go through
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 3 Dec 2007 23:10

Re: [patch 01/19] Define functions for page cache handling

On Fri, 30 Nov 2007 09:34:49 -0800
Christoph Lameter <clameter <at> sgi.com> wrote:

> We use the macros PAGE_CACHE_SIZE PAGE_CACHE_SHIFT PAGE_CACHE_MASK
> and PAGE_CACHE_ALIGN in various places in the kernel. Many times
> common operations like calculating the offset or the index are coded
> using shifts and adds. This patch provides inline functions to
> get the calculations accomplished without having to explicitly
> shift and add constants.
> 
> All functions take an address_space pointer. The address space pointer
> will be used in the future to eventually support a variable size
> page cache. Information reachable via the mapping may then determine
> page size.
> 
> New function                    Related base page constant
> ====================================================================
> page_cache_shift(a)             PAGE_CACHE_SHIFT
> page_cache_size(a)              PAGE_CACHE_SIZE
> page_cache_mask(a)              PAGE_CACHE_MASK
> page_cache_index(a, pos)        Calculate page number from position
> page_cache_next(addr, pos)      Page number of next page
> page_cache_offset(a, pos)       Calculate offset into a page
> page_cache_pos(a, index, offset)
>                                 Form position based on page number
>                                 and an offset.
> 
> This provides a basis that would allow the conversion of all page cache
> handling in the kernel and ultimately allow the removal of the PAGE_CACHE_*
> constants.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane