(unknown)

(unknown)

[Linus Torvalds]

Trond?

See 'http://lkml.org/lkml/2008/7/17/154'? It's been 10+ days, it's 
apparently still there.

		Linus

RE:

[Trond Myklebust]

On Sun, 2008-07-27 at 10:40 -0700, Linus Torvalds wrote:
> Trond?
> 
> See 'http://lkml.org/lkml/2008/7/17/154'? It's been 10+ days, it's 
> apparently still there.
> 
> 		Linus

Sure thing...

Please pull from the "hotfixes" branch of the repository at

   git pull git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git hotfixes

This will update the following files through the appended changesets.

  Cheers,
    Trond

----
 fs/nfs/super.c  |    6 +++---
 fs/nfs/unlink.c |    3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

commit 744d18dbfae07482ea461701b0aaec3a75ec9224
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Sun Jul 27 18:03:19 2008 -0400

    NFS: Ensure we call nfs_sb_deactive() after releasing the directory inode
    
    In order to avoid the "Busy inodes after unmount" error message, we need to
    ensure that nfs_async_unlink_release() releases the super block after the
    call to nfs_free_unlinkdata().
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 31c9446993f412ecb7875e30bba4bc7f216ae016
Author: Marc Zyngier <maz@misterjones.org>
Date:   Thu Jul 17 13:21:55 2008 +0200

    nfs_remount oops when rebooting + possible fix
    
    Jeff, Trond,
    
    The commit
    
    48b605f83c920d8daa50e43fc2c7f718e04c7bfa (NFS: implement option checking
    when remounting NFS filesystems (resend))
    
    generate an Oops on my platform when rebooting while its root FS on
    an NFS share (NFSv3, TCP) :
    
    Unmounting local filesystems...done.
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c3d00000
    [00000000] *pgd=a3d72031, *pte=00000000, *ppte=00000000
    Internal error: Oops: 17 [#1]
    Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative ext3 jbd sd_mod pata_pcmcia libata scsi_mod pcmcia loop firmware_class pxafb cfbcopyarea cfbimgblt cfbfillrect pxa2xx_cs pxa2xx_core pcmcia_core snd_pxa2xx_ac97 snd_ac97_codec ac97_bus snd_pxa2xx_pcm snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd isp116x_hcd soundcore rtc_sa1100 snd_page_alloc pxa25x_udc usbcore rtc_ds1307 rtc_core
    CPU: 0    Not tainted  (2.6.26-03414-g33af79d-dirty #15)
    PC is at nfs_remount+0x40/0x264
    LR is at do_remount_sb+0x158/0x194
    pc : [<c00bbf54>]    lr : [<c0076c40>]    psr: 60000013
    sp : c2dd1e70  ip : c2dd1e98  fp : c2dd1e94
    r10: 00000040  r9 : c3d17000  r8 : c3c3fc40
    r7 : 00000000  r6 : 00000000  r5 : c3d2b200  r4 : 00000000
    r3 : 00000003  r2 : 00000000  r1 : c2dd1e9c  r0 : c3c3fc00
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 0000397f  Table: a3d00000  DAC: 00000015
    Process mount (pid: 1462, stack limit = 0xc2dd0270)
    Stack: (0xc2dd1e70 to 0xc2dd2000)
    1e60:                                     00000000 c3c3fc00 00000000 00000000
    1e80: c3c3fc40 c3d17000 c2dd1ebc c2dd1e98 c0076c40 c00bbf20 c01c61e4 00000001
    1ea0: c2dd1ebc 00000001 c3c3fc00 c2dd1ef0 c2dd1ee4 c2dd1ec0 c008c6d8 c0076af4
    1ec0: 00000021 00000040 c2dd1ef0 c3d77000 c3eaa000 00000000 c2dd1f6c c2dd1ee8
    1ee0: c008d1bc c008c5f8 00000000 c2dd0000 c3c0c320 c3805b38 c002064c 0001f820
    1f00: 0001f810 00000001 00000001 00000000 c2dd0000 00000000 c2dd1f34 c2dd1f28
    1f20: c005ead8 c005e6f8 c2dd1f44 c2dd1f38 c005eaf8 c005ead0 c2dd1f6c c2dd1f48
    1f40: c008ae3c 00000000 c3d77000 0001f810 c0ed0021 c0020ca8 c2dd0000 00000000
    1f60: c2dd1fa4 c2dd1f70 c008d2d4 c008d0bc 00000000 0001f810 c2dd1f9c c3eaa000
    1f80: c3d17000 00000000 00000000 be8b6aa8 be8b6ad0 00000015 00000000 c2dd1fa8
    1fa0: c0020b00 c008d254 00000000 be8b6aa8 0001f810 0001f820 0001f830 c0ed0021
    1fc0: 00000000 be8b6aa8 be8b6ad0 00000015 00000000 be8b6ad0 0001f810 be8b6aa8
    1fe0: 0001f810 be8b6964 0000aab8 40125124 60000010 0001f810 00000000 00000000
    Backtrace:
    [<c00bbf14>] (nfs_remount+0x0/0x264) from [<c0076c40>] (do_remount_sb+0x158/0x194)
      r9:c3d17000 r8:c3c3fc40 r7:00000000 r6:00000000 r5:c3c3fc00
    r4:00000000
    [<c0076ae8>] (do_remount_sb+0x0/0x194) from [<c008c6d8>] (do_remount+0xec/0x118)
      r6:c2dd1ef0 r5:c3c3fc00 r4:00000001
    [<c008c5ec>] (do_remount+0x0/0x118) from [<c008d1bc>] (do_mount+0x10c/0x198)
    [<c008d0b0>] (do_mount+0x0/0x198) from [<c008d2d4>] (sys_mount+0x8c/0xd4)
    [<c008d248>] (sys_mount+0x0/0xd4) from [<c0020b00>] (ret_fast_syscall+0x0/0x2c)
      r7:00000015 r6:be8b6ad0 r5:be8b6aa8 r4:00000000
    Code: 0a000086 ea000006 e3530003 8a000004 (e5923000)
    ---[ end trace 55e1b689cf8c8a6a ]---
    ------------[ cut here ]------------
    WARNING: at kernel/exit.c:966 do_exit+0x3c/0x628()
    Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative ext3 jbd sd_mod pata_pcmcia libata scsi_mod pcmcia loop firmware_class pxafb cfbcopyarea cfbimgblt cfbfillrect pxa2xx_cs pxa2xx_core pcmcia_core snd_pxa2xx_ac97 snd_ac97_codec ac97_bus snd_pxa2xx_pcm snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd isp116x_hcd soundcore rtc_sa1100 snd_page_alloc pxa25x_udc usbcore rtc_ds1307 rtc_core
    [<c0025168>] (dump_stack+0x0/0x14) from [<c0032154>] (warn_on_slowpath+0x4c/0x68)
    [<c0032108>] (warn_on_slowpath+0x0/0x68) from [<c003531c>] (do_exit+0x3c/0x628)
      r6:0000000b r5:c3c3dc80 r4:c2dd0000
    [<c00352e0>] (do_exit+0x0/0x628) from [<c0025004>] (die+0x2b0/0x30c)
    [<c0024d54>] (die+0x0/0x30c) from [<c00270bc>] (__do_kernel_fault+0x6c/0x80)
    [<c0027050>] (__do_kernel_fault+0x0/0x80) from [<c00272e0>] (do_page_fault+0x210/0x230)
      r7:c3fa7118 r6:c3c3dc80 r5:c3d166a8 r4:00010000
    [<c00270d0>] (do_page_fault+0x0/0x230) from [<c00201ec>] (do_DataAbort+0x3c/0xa0)
    [<c00201b0>] (do_DataAbort+0x0/0xa0) from [<c002064c>] (__dabt_svc+0x4c/0x60)
    Exception stack(0xc2dd1e28 to 0xc2dd1e70)
    1e20:                   c3c3fc00 c2dd1e9c 00000000 00000003 00000000 c3d2b200
    1e40: 00000000 00000000 c3c3fc40 c3d17000 00000040 c2dd1e94 c2dd1e98 c2dd1e70
    1e60: c0076c40 c00bbf54 60000013 ffffffff
      r8:c3c3fc40 r7:00000000 r6:00000000 r5:c2dd1e5c r4:ffffffff
    [<c00bbf14>] (nfs_remount+0x0/0x264) from [<c0076c40>] (do_remount_sb+0x158/0x194)
      r9:c3d17000 r8:c3c3fc40 r7:00000000 r6:00000000 r5:c3c3fc00
    r4:00000000
    [<c0076ae8>] (do_remount_sb+0x0/0x194) from [<c008c6d8>] (do_remount+0xec/0x118)
      r6:c2dd1ef0 r5:c3c3fc00 r4:00000001
    [<c008c5ec>] (do_remount+0x0/0x118) from [<c008d1bc>] (do_mount+0x10c/0x198)
    [<c008d0b0>] (do_mount+0x0/0x198) from [<c008d2d4>] (sys_mount+0x8c/0xd4)
    [<c008d248>] (sys_mount+0x0/0xd4) from [<c0020b00>] (ret_fast_syscall+0x0/0x2c)
      r7:00000015 r6:be8b6ad0 r5:be8b6aa8 r4:00000000
    ---[ end trace 55e1b689cf8c8a6a ]---
    /etc/rc6.d/S60umountroot: line 17:  1462 Segmentation fault      mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2> /dev/null
    
    The new super.c:nfs_remount function doesn't check the validity of the
    options/options4 pointers. Unfortunately, this seems to happend.
    The obvious patch seems to check the pointers, and not to do anything if
    the happend to be NULL.
    
    Tested on an XScale PXA255 system, latest git.
    
    Regards,
    
    	M.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@altran.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 1b94e36..9abcd2b 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1718,9 +1718,9 @@ nfs_remount(struct super_block *sb, int *flags, char *raw_data)
 	 * ones were explicitly specified. Fall back to legacy behavior and
 	 * just return success.
 	 */
-	if ((nfsvers == 4 && options4->version == 1) ||
-	    (nfsvers <= 3 && options->version >= 1 &&
-	     options->version <= 6))
+	if ((nfsvers == 4 && (!options4 || options4->version == 1)) ||
+	    (nfsvers <= 3 && (!options || (options->version >= 1 &&
+					   options->version <= 6))))
 		return 0;
 
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 3adf8b2..f089e58 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -95,10 +95,11 @@ static void nfs_async_unlink_done(struct rpc_task *task, void *calldata)
 static void nfs_async_unlink_release(void *calldata)
 {
 	struct nfs_unlinkdata	*data = calldata;
+	struct super_block *sb = data->dir->i_sb;
 
 	nfs_dec_sillycount(data->dir);
-	nfs_sb_deactive(NFS_SERVER(data->dir));
 	nfs_free_unlinkdata(data);
+	nfs_sb_deactive(NFS_SB(sb));
 }
 
 static const struct rpc_call_ops nfs_unlink_ops = {


-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

(unknown),

[pepa6.es-sh/6fXdz2Rs]

Proposal,

Respond to my personal email;  mrs.zhangxiao1962@outlook.
com 


Yours Sincerely.
Mrs. Zhang Xiao (Accounts book Keeper)
Angang 
Steel Company Limited
396 Nan Zhong Hua Lu, Tie Dong District Anshan, 
Liaoning 114021, China.

(unknown)

[MRS GRACE MANDA]

[-- Attachment #1: Type: text/plain, Size: 71 bytes --]









This is Mrs Grace Manda (  Please I need your Help is Urgent). 

[-- Attachment #2: Mrs Grace Manda.rtf --]
[-- Type: application/rtf, Size: 35796 bytes --]

(unknown),

[Christian Organization]

Good day,

We are Christian organization, we give loan to those who are dedicated
Christians, contact us at mercantilefinanceloanservice@yahoo.com

Regard

Mercantile

(unknown),

[Allen and Violet Large]

Dear Sir/Madam,

This is my fifth times of writting you this email since last year till
date but no response from you.Hope you get this one, as this is a personal
email directed to you. My wife and I won a Jackpot Lotteryof $11.3 million
in July and have voluntarily decided to donate the sum of $500,000.00 USD
to you as part of our own charity project to improve the lot of 10 lucky
individuals all over the world. If you have received this email then you
are one of the lucky recipients and all you have to do is get back with us
so that we can send your details to the payout bank.Please note that you
have to contact my private email for more
informations(allen-violetlarge11-W+jws2TpwOvR7s880joybQ@public.gmane.org)

You can verify this by visiting the web pages below.



http://www.dailymail.co.uk/news/article-1326473/Canadian-couple-Allen-Violet-Large-away-entire-11-2m-lottery-win.html


Goodluck,
Allen and Violet Large
allen-violetlarge11-W+jws2TpwOvR7s880joybQ@public.gmane.org

(unknown),

[Mrs Mellisa Lewis.]

Contact My Lawyer For More Details,!! Barr jay mchenry for  
$14,258,000.00 tell him that i have will this money to  
you.Ref:(JJ/MMS/953/5015/GwrI/316us/uk For charity organization in  
your country.Email:(bjmfirm-N/I+a4o3xEsAvxtiuMwx3w@public.gmane.org) Tel: +44703 183 9543,God Bless  
You Mrs Mellisa Lewis.

(unknown)

[Christoph Neuhaus]

unsubscribe linux-nfs

(unknown)

[Silver gears]

(unknown), ,

[Ming-Yang Lee]

Do you need a loan to pay your bills or to start up a business or for Xmas?.
Kindly apply now for a low rate loan of 3%. for more information contact:
ming.yangfundsservice-HzS2SGvssRM@public.gmane.org
We Await Your Response.
Mr Ming-Yang Lee

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

(unknown)

[Fredrik Pettersson]

unsubscribe linux-nfs

(unknown),

[Grant Mayor]

FUNDING NOTIFICATION.............I am Mr Grant Mayor. i am a loan lender
as well as an angel investor, I offer funds based on demands and i use the
best possible interest rate so that it can make both paties smile. I allow
my clients to decide the loan repayment duration. So i have my door for
funding opened to all that is in need, If you have been turned down be
many financial institutions, this is a great time for you to make things
up. If you need a stress free funing, kindly get back to me with a mail of
application for funding and you will get funded within 3 working days.
Send all mails of application to: to.grantfinancing-Re5JQEeQqe9fmgfxC/sS/w@public.gmane.org

I await your response.

Grant Mayor.

(unknown),

[andros]

This is against the pnfs-submit branch of the 2.6.34 tree. They will need to be
applied against the 2.6.35-rc1 tree which I can do after comments.

RFC: I would like comments, especially on
0006-SQUASHME-pnfs-submit-move-layoutcommit-to-nfs_write_.patch.

Remove unused layoutcommit layoutdriver_io_operations. Will be restored
in post-submit patches
0001-SQUASHME-pnfs-submit-remove-setup_layoutcommit.patch
0002-SQUASHNE-pnfs-submit-remove-cleanup_layoutcommit.patch
0003-SQUASHME-pnfs-submit-remove-encode_layoutcommit.patch

A cleanup, and call the async error handler.
0004-SQUASHME-pnfs-submit-cleanup-layoutcommit-call.patch
0005-SQUASHME-pnfs-submit-handle-async-layoutcommit-error.patch

This next  patch moves the pnfs_layoutcommit_inode call to nfs_write_inode,
and it is the only call other than in layoutreturn. (removed calls in
__nfs4_close, nfs_commit_inode, nfs_wb_sync).

This is fine for the file layout, and I think it's OK for the object and
block layouts as well.

I left the LAYOUTCOMMIT call in nfs_write_inode a synchronous call, because
nfs_commit_unstable_pages sets the FLUSH_SYNC flag. Should this
be an asyc LAYOUTCOMMIT call?

pnfs_layoutcommit_inode is called after nfs_commit_unstable_pages() so that
if LAYOUTCOMMIT fails, the unstable pages have been processed..

The error handlers (sync and async) call nfs4_map_errors, so unhandled
errors (such as NFS4ERR_BADLAYOUT) get returned to nfs_write_ioode as -EIO.

Examining the write_inode call paths, I could not see where the -EIO would
be passed back to the application.  Testing with pynfs which I
had return NFS4ERR_BADLAYOUT to the layout commit call, shows the -EIO return
not stopping the client nor is the error reported back to the application.

We will add code to the error handlers for errors such as NFS4ERR_BADLAYOUT 
that require us to stop using and free the layout, and redo the I/O through
the MDS.

Anyway, review is much appreciated.

0006-SQUASHME-pnfs-submit-move-layoutcommit-to-nfs_write_.patch

Testing:
With CONFIG_NFS_V4_1 set
NFSv4.1/pnfs passed Connectathon against write enabled GFS2/pNFS. Note: there
were exactly the same number of LAYOUTCOMMITS sent as were sent with
pnfs_layoutcommit_inode being called from __nfs4_close (never happened),
nfs_commit_inode and nfs_wb_sync.

Passed Connectathon general test against pynfs file layout server with
the NFS4ERR_BADLAYOUT being returned on every third LAYOUTCOMMIT.


-->Andy

(unknown)

[Maurice Volaski]

subscribe nfs

(unknown),

[andros]

All layout drivers returned -1 or 0 for both get_read_threshold and
get_write_threshold policy operations. Remove the threshold policy ops and
the related helper functions.

Note that the threshold

0001-SQUASHME-pnfs_submit-remove-filelayout-get-threshold.patch
0002-SQUASHME-pnfs_submit-don-t-use-pnfs_use_read.patch
0003-SQUASHME-pnfs_submit-don-t-use-pnfs_use_write.patch
0004-SQUASHME-pnfs_submit-don-t-use-pnfs_use_write-for-co.patch
0005-SQUASHME-pnfs_submit-don-t-use-pg_threshold.patch
0006-SQUASHME-pnfs_submit-remove-pg_threshold.patch
0007-SQUASHME-pnfs_submit-don-t-use-below_threshold-in-re.patch
0008-SQUASHME-pnfs_submit-don-t-use-below_threshold-in-di.patch
0009-SQUASHME-pnfs_submit-remove-unused-threshold-calcula.patch
0010-SQUASHME-pnfs_submit-cleanup-filelayout-pg_test.patch

Note: these will not be restored.

Testing:
--------
CONFIG_NFS4_V1 set:
v4, v4.1, pNFS mounts Connectathon passes

CONFIG_NFS4_V1 not set:
v4 mount Connectathon passes

-->Andy

(unknown)

[vivianofferplc013-+MseY0pMZYIAvxtiuMwx3w]

This is a Financial Service Announcement, we offer loan to all in need,ranging from $5000 to $800,000.00 USD. Our interest rate is 3% and our service and terms are dependable. any interested person should apply via email:lapoloanlender@gmail.com

(unknown)

[Eric Sesterhenn]

hi,

with todays -git i see the following lockdep warning, that wasnt there
yesterday. It occurs after booting the box.

[   83.741022] Installing knfsd (copyright (C) 1996 okir-pn4DOG8n3UYbFoVRYvo4fw@public.gmane.org).
[   84.115838] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
recovery directory
[   84.133473] NFSD: starting 90-second grace period
[  174.132715] 
[  174.132724] =============================================
[  174.133004] [ INFO: possible recursive locking detected ]
[  174.133133] 2.6.28 #85
[  174.133232] ---------------------------------------------
[  174.133428] nfsd4/3693 is trying to acquire lock:
[  174.133548]  (&type->i_mutex_dir_key#2){--..}, at: [<c01c4212>]
vfs_fsync+0x62/0xe0
[  174.133991] 
[  174.133994] but task is already holding lock:
[  174.134251]  (&type->i_mutex_dir_key#2){--..}, at: [<d1c224f7>]
nfsd4_sync_rec_dir+0x17/0x40 [nfsd]
[  174.134774] 
[  174.134777] other info that might help us debug this:
[  174.134983] 4 locks held by nfsd4/3693:
[  174.135151]  #0:  (nfsd4){--..}, at: [<c0139d4a>]
run_workqueue+0x7a/0x1e0
[  174.135539]  #1:  ((laundromat_work).work){--..}, at: [<c0139d4a>]
run_workqueue+0x7a/0x1e0
[  174.135968]  #2:  (client_mutex){--..}, at: [<d1c1e9f6>]
laundromat_main+0x26/0x2a0 [nfsd]
[  174.136021]  #3:  (&type->i_mutex_dir_key#2){--..}, at: [<d1c224f7>]
nfsd4_sync_rec_dir+0x17/0x40 [nfsd]
[  174.136021] 
[  174.136021] stack backtrace:
[  174.136021] Pid: 3693, comm: nfsd4 Not tainted 2.6.28 #85
[  174.136021] Call Trace:
[  174.136021]  [<c05abdb6>] ? printk+0x18/0x1a
[  174.136021]  [<c014f626>] __lock_acquire+0xe76/0x1110
[  174.136021]  [<c014f934>] lock_acquire+0x74/0xa0
[  174.136021]  [<c01c4212>] ? vfs_fsync+0x62/0xe0
[  174.136021]  [<c05acfac>] mutex_lock_nested+0x8c/0x2c0
[  174.136021]  [<c01c4212>] ? vfs_fsync+0x62/0xe0
[  174.136021]  [<c01c4212>] ? vfs_fsync+0x62/0xe0
[  174.136021]  [<c01c4212>] vfs_fsync+0x62/0xe0
[  174.136021]  [<d1c074be>] nfsd_sync_dir+0xe/0x10 [nfsd]
[  174.136021]  [<d1c22501>] nfsd4_sync_rec_dir+0x21/0x40 [nfsd]
[  174.136021]  [<d1c22595>] nfsd4_recdir_purge_old+0x75/0x80 [nfsd]
[  174.136021]  [<d1c1ea1e>] laundromat_main+0x4e/0x2a0 [nfsd]
[  174.136021]  [<c0139d4a>] ? run_workqueue+0x7a/0x1e0
[  174.136021]  [<c0139dac>] run_workqueue+0xdc/0x1e0
[  174.136021]  [<c0139d4a>] ? run_workqueue+0x7a/0x1e0
[  174.136021]  [<d1c1e9d0>] ? laundromat_main+0x0/0x2a0 [nfsd]
[  174.136021]  [<c013a1a7>] worker_thread+0x87/0xf0
[  174.136021]  [<c013dac0>] ? autoremove_wake_function+0x0/0x50
[  174.136021]  [<c013a120>] ? worker_thread+0x0/0xf0
[  174.136021]  [<c013d80a>] kthread+0x3a/0x70
[  174.136021]  [<c013d7d0>] ? kthread+0x0/0x70
[  174.136021]  [<c0103cf3>] kernel_thread_helper+0x7/0x14

Greetings, Eric

(unknown),

[Sagar Borikar]

unsubscribe

(unknown)

[George Cameron]

subscribe linux-nfs

Re: [PATCH] locks: provide a file lease method enabling cluster-coherent leases

[J. Bruce Fields]

On Thu, Jun 07, 2007 at 10:43:51AM -0400, Robert Rappaport wrote:
> My interpretation of the preceeding is  that there is agreement that
> the functionality currently implemented in __setlease() should be
> exported, even though the exported name may not be __setlease().  Is
> this correct?

Yes.

> If so, that is just fine with me.

OK, good.  I'll revise and post a new series.  (Do people prefer another
mailbomb or a git url?)

> The question that I have now is when do you think it likely that these
> changes get into the released code?  I hope that the plan is to get it
> there fairly soon.

It would seem reasonable to me to put off the question of how to do proper
distributed lease-breaking for now, in which case the remaining patches
seem straightforward enough to me that they could go in now.

My main question is whether the partial disabling of leases looks to the
GFS2 people like reasonable behavior.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(unknown),

[J. Bruce Fields]

J. Bruce Fields <bfields@fieldses.org> wrote:
> OK, good.  I'll revise and post a new series.  (Do people prefer
> another mailbomb or a git url?)

OK, I went for the former; if you'd rather get this out of git, you can

	git clone http://www.linux-nfs.org/~bfields/linux.git
	git checkout server-cluster-lease-api

The changes from the last version seem pretty trivial, but I've
compile-tested this only for now.

I'm ignoring the problem of breaking leases on unlink and rename.  I
think we should go ahead and do this part now--it's adequate for the
current lease semantics, and even more so for our current application
(just turning off leases selectively on some filesystems)--but I'd
really like to solve that problem eventually.

That's probably not going to happen until we get a cluster filesystem
with real lease support into the kernel....

Changes:
	- do away with the break_lease method.
	- rename __setlease to setlease, setlease to vfs_setlease, and
	  make sure it's setlease (the one that doesn't call into the
	  filesystem) that's exported.
	- rename ->set_lease to ->setlease.  (I don't really care which
	  we go with, it just seemed confusing when everything else was
	  already named without the underscore.)
	- Add a trivial patch that disables leases on nfs (as suggested
	  by a patch elsewhere from Peter Staubach)

--b.