headers
Milo | 1 May 2006 04:41
Picon

meet me soon

Hi there lovelay,
I was searching the net few days ago. I bam new to this thing.
and saaw your profile. I decided to email yoau cause I fobund 
you atatractive. I might come down to your city in few weeks.
Let me know if we can meet eaach other in person.
I am aattbractive girl.b I am sure you won't regret it.
Reply to my personal email at wt <at> popmailme.com

-
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
Ian Kent | 1 May 2006 12:56
Favicon

[PATCH] autofs4 - NFY_NONE wait race fix


Hi Andrew,

This patch fixes two problems.

First, the comparison of entries in the waitq.c was incorrect.

Second, the NFY_NONE check was incorrect. The test of whether the dentry 
is mounted if ineffective, for example, if an expire fails then we could 
wait forever on a non existant expire. The bug was identified by Jeff 
Moyer.

The patch changes autofs4 to wait on expires only as this is all that's 
needed. If there is no existing wait when autofs4_wait is call with 
a type of NFY_NONE it delays until either a wait appears or the the expire 
flag is cleared.

Signed-off-by: Ian Kent <raven <at> themaw.net>

--

--- linux-2.6.17-rc1-mm3/fs/autofs4/autofs_i.h.nfy_none-wait-race-fix	2006-04-26
15:19:41.000000000 +0800
+++ linux-2.6.17-rc1-mm3/fs/autofs4/autofs_i.h	2006-04-26 15:20:25.000000000 +0800
 <at>  <at>  -74,8 +74,8  <at>  <at> 
 	struct autofs_wait_queue *next;
 	autofs_wqt_t wait_queue_token;
 	/* We use the following to see what we are waiting for */
-	int hash;
-	int len;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wendy Cheng | 1 May 2006 21:00
Picon
Favicon

Re: [PATCH 04/16] GFS2: Daemons and address space operations

Steven Whitehouse wrote

>+static int gfs2_writepage(struct page *page, struct writeback_control *wbc)
>+{
>+	struct inode *inode = page->mapping->host;
>+	struct gfs2_inode *ip = page->mapping->host->u.generic_ip;
>+	struct gfs2_sbd *sdp = ip->i_sbd;
>+	loff_t i_size = i_size_read(inode);
>+	pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT;
>+	unsigned offset;
>+	int error;
>+	int done_trans = 0;
>+
>+	if (gfs2_assert_withdraw(sdp, gfs2_glock_is_held_excl(ip->i_gl))) {
>+		unlock_page(page);
>+		return -EIO;
>+	}
>+	if (current->journal_info)
>+		goto out_ignore;
>+
>+	/* Is the page fully outside i_size? (truncate in progress) */
>+        offset = i_size & (PAGE_CACHE_SIZE-1);
>+	if (page->index >= end_index+1 || !offset) {
>+		page->mapping->a_ops->invalidatepage(page, 0);
>+		unlock_page(page);
>+		return 0; /* don't care */
>+	}
>
>  
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Kent | 2 May 2006 07:56
Favicon

[RFC] Multiple server selection and replicated mount failover


Hi all,

For some time now I have had code in autofs that attempts to select an 
appropriate server from a weighted list to satisfy server priority 
selection and Replicated Server requirements. The code has been 
problematic from the beginning and is still incorrect largely due to me 
not merging the original patch well and also not fixing it correctly 
afterward.

So I'd like to have this work properly and to do that I also need to 
consider read-only NFS mount fail over.

The rules for server selection are, in order of priority (I believe):

1) Hosts on the local subnet.
2) Hosts on the local network.
3) Hosts on other network.

Each of these proximity groups is made up of the largest number of 
servers supporting a given NFS protocol version. For example if there were 
5 servers and 4 supported v3 and 2 supported v2 then the candidate group 
would be made up of the 4 supporting v3. Within the group of candidate 
servers the one with the best response time is selected. Selection 
within a proximity group can be further influenced by a zero based weight 
associated with each host. The higher the weight (a cost really) the less 
likely a server is to be selected. I'm not clear on exactly how he weight 
influences the selection, so perhaps someone who is familiar with this 
could explain it?
(Continue reading)

Permalink | Reply | 49 comments |
headers
Steve Dickson | 2 May 2006 11:49
Picon
Favicon

Re: [PATCH][RFC] NFS: Improving the access cache

Neil Brown wrote:
>>To rephrase to make sure I understand....
>>1) P1(uid=1) creates an access pointer in the nfs_inode
>>2) P2(uid=2) sees the access pointer is not null so it adds them both
>>    to the table, right?
>>
> 
> 
> Exactly.
> 
> 
>>>We would need to be able to tell from the inode whether anything is
>>>hashed or not.  This could simply be if the nfs_access_entry point is
>>>non-null, and its hashlist it non-empty.  Or we could just use a bit
>>>flag somewhere.
>>
>>So I guess it would be something like:
>>if (nfs_inode->access == null)
>>     set nfs_inode->access
>>if (nfs_inode->access =! NULL && nfs_inode->access_hash == empty)
>>     move both pointer into hast able.
>>if (nfs_inode->access == null && nfs_inode->access_hash != empty)
>>     use hastable.
>>
>>But now the question is how would I know when there is only one
>>entry in the table? Or do we just let the hash table "drain"
>>naturally and when it become empty we start with the nfs_inode->access
>>pointer again... Is this close to what your thinking??
> 
>
(Continue reading)

Permalink | Reply | 31 comments |
headers
Steven Whitehouse | 2 May 2006 14:43
Picon
Favicon

Re: [PATCH 04/16] GFS2: Daemons and address space operations

Hi,

On Mon, 2006-05-01 at 15:00 -0400, Wendy Cheng wrote:
> Steven Whitehouse wrote
> 
> >+static int gfs2_writepage(struct page *page, struct writeback_control *wbc)
> >+{
> >+	struct inode *inode = page->mapping->host;
> >+	struct gfs2_inode *ip = page->mapping->host->u.generic_ip;
> >+	struct gfs2_sbd *sdp = ip->i_sbd;
> >+	loff_t i_size = i_size_read(inode);
> >+	pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT;
> >+	unsigned offset;
> >+	int error;
> >+	int done_trans = 0;
> >+
> >+	if (gfs2_assert_withdraw(sdp, gfs2_glock_is_held_excl(ip->i_gl))) {
> >+		unlock_page(page);
> >+		return -EIO;
> >+	}
> >+	if (current->journal_info)
> >+		goto out_ignore;
> >+
> >+	/* Is the page fully outside i_size? (truncate in progress) */
> >+        offset = i_size & (PAGE_CACHE_SIZE-1);
> >+	if (page->index >= end_index+1 || !offset) {
> >+		page->mapping->a_ops->invalidatepage(page, 0);
> >+		unlock_page(page);
> >+		return 0; /* don't care */
> >+	}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Staubach | 2 May 2006 15:51
Picon
Favicon

Re: [NFS] Re: [PATCH][RFC] NFS: Improving the access cache

Steve Dickson wrote:

> Neil Brown wrote:
>
>>> To rephrase to make sure I understand....
>>> 1) P1(uid=1) creates an access pointer in the nfs_inode
>>> 2) P2(uid=2) sees the access pointer is not null so it adds them both
>>>    to the table, right?
>>>
>>
>>
>> Exactly.
>>
>>
>>>> We would need to be able to tell from the inode whether anything is
>>>> hashed or not.  This could simply be if the nfs_access_entry point is
>>>> non-null, and its hashlist it non-empty.  Or we could just use a bit
>>>> flag somewhere.
>>>
>>>
>>> So I guess it would be something like:
>>> if (nfs_inode->access == null)
>>>     set nfs_inode->access
>>> if (nfs_inode->access =! NULL && nfs_inode->access_hash == empty)
>>>     move both pointer into hast able.
>>> if (nfs_inode->access == null && nfs_inode->access_hash != empty)
>>>     use hastable.
>>>
>>> But now the question is how would I know when there is only one
>>> entry in the table? Or do we just let the hash table "drain"
(Continue reading)

Permalink | Reply | 6 comments |
headers
Steve Dickson | 2 May 2006 16:38
Picon
Favicon

Re: [NFS] Re: [PATCH][RFC] NFS: Improving the access cache

Peter Staubach wrote:
>> Basically we would maintain one global hlist (i.e. link list) that
>> would contain all of the cached entries; then each nfs_inode would
>> have its own LRU hlist that would contain entries that are associated
>> with that nfs_inode. So each entry would be on two lists, the
>> global hlist and hlist in the nfs_inode.
>>
> 
> How are these lists used?
The inode hlist will be used to search and purge...

> 
> I would suggest that a global set of hash queues would work better than
> a linked list and that these hash queues by used to find the cache entry
> for any particular user.  Finding the entry for a particular (user,inode)
> needs to be fast and linearly searching a linked list is slow.  Linear
> searching needs to be avoided.  Comparing the fewest number of entries
> possible will result in the best performance because the comparisons
> need to take into account the entire user identification, including
> the groups list.
I guess we could have the VFS  shrinker to purge a hash table just
as well as a link list... although a hash table will have an
small memory cost...

> The list in the inode seems useful, but only for purges.  Searching via
> this list will be very slow once the list grows beyond a few entries.
> Purging needs to be fast because purging the access cache entries for a
> particular file will need to happen whenever the ctime on the file changes.
> This list can be used to make it easy to find the correct entries in the
> global access cache.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Peter Staubach | 2 May 2006 16:51
Picon
Favicon

Re: Re: [PATCH][RFC] NFS: Improving the access cache

Steve Dickson wrote:

> Peter Staubach wrote:
>
>>> Basically we would maintain one global hlist (i.e. link list) that
>>> would contain all of the cached entries; then each nfs_inode would
>>> have its own LRU hlist that would contain entries that are associated
>>> with that nfs_inode. So each entry would be on two lists, the
>>> global hlist and hlist in the nfs_inode.
>>>
>>
>> How are these lists used?
>
> The inode hlist will be used to search and purge...
>

Eeee!  A linear search?  That gets expensive as the list grows.  A hashed
list would keep the search times down.

>>
>> I would suggest that a global set of hash queues would work better than
>> a linked list and that these hash queues by used to find the cache entry
>> for any particular user.  Finding the entry for a particular 
>> (user,inode)
>> needs to be fast and linearly searching a linked list is slow.  Linear
>> searching needs to be avoided.  Comparing the fewest number of entries
>> possible will result in the best performance because the comparisons
>> need to take into account the entire user identification, including
>> the groups list.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Kent | 2 May 2006 17:26
Favicon

Re: [NFS] Re: [PATCH][RFC] NFS: Improving the access cache

On Tue, 2 May 2006, Peter Staubach wrote:

> Steve Dickson wrote:
> 
> > Peter Staubach wrote:
> > 
> > > > Basically we would maintain one global hlist (i.e. link list) that
> > > > would contain all of the cached entries; then each nfs_inode would
> > > > have its own LRU hlist that would contain entries that are associated
> > > > with that nfs_inode. So each entry would be on two lists, the
> > > > global hlist and hlist in the nfs_inode.
> > > > 
> > > 
> > > How are these lists used?
> > 
> > The inode hlist will be used to search and purge...
> > 
> 
> Eeee!  A linear search?  That gets expensive as the list grows.  A hashed
> list would keep the search times down.

I thought hlist was meant to be used for hash tables with chaining?

Ian

-
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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane