Re: [PATCH] NFS: Fix mode bits and nlink count for v4 referral dirs

gt; tron...@hammerspace.com> wrote: > >>> > >>> On Thu, 2020-10-15 at 00:39 +0530, Ashish Sangwan wrote: > >>>> On Wed, Oct 14, 2020 at 11:47 PM Trond Myklebust > >>>> wrote: > >>>>> On Tue, 2020-10-06 at 08:14 -0700, Ashi

Re: [PATCH] NFS: Fix mode bits and nlink count for v4 referral dirs

On Wed, Oct 14, 2020 at 11:47 PM Trond Myklebust wrote: > > On Tue, 2020-10-06 at 08:14 -0700, Ashish Sangwan wrote: > > Request for mode bits and nlink count in the nfs4_get_referral call > > and if server returns them use them instead of hard coded values. > > > &

[PATCH] NFS: Fix mode bits and nlink count for v4 referral dirs

Request for mode bits and nlink count in the nfs4_get_referral call and if server returns them use them instead of hard coded values. CC: sta...@vger.kernel.org Signed-off-by: Ashish Sangwan --- fs/nfs/nfs4proc.c | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) diff

[PATCH] NFS: fix nfs_path in case of a rename retry

We are generating incorrect path in case of rename retry because we are restarting from wrong dentry. We should restart from the dentry which was received in the call to nfs_path. CC: sta...@vger.kernel.org Signed-off-by: Ashish Sangwan --- fs/nfs/namespace.c | 12 1 file changed

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 4:55 PM, Miklos Szeredi <mik...@szeredi.hu> wrote: > On Thu, Apr 7, 2016 at 1:48 PM, Ashish Sangwan <ashishsangw...@gmail.com> > wrote: >> While sending the blocking directIO in fuse, the write request is broken >> into sub-requests, eac

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 4:55 PM, Miklos Szeredi wrote: > On Thu, Apr 7, 2016 at 1:48 PM, Ashish Sangwan > wrote: >> While sending the blocking directIO in fuse, the write request is broken >> into sub-requests, each of default size 128k and all the requests are sent

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

Hi Miklos, Did you get any time to look into the patch? Its been more than two months. On Thu, Apr 14, 2016 at 6:02 PM, Ashish Sangwan <ashishsangw...@gmail.com> wrote: > *ping* > > Last time it bounced off the fuse mailing list. > > On Thu, Apr 7, 2016 at 5:18 PM, Ashish

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

Hi Miklos, Did you get any time to look into the patch? Its been more than two months. On Thu, Apr 14, 2016 at 6:02 PM, Ashish Sangwan wrote: > *ping* > > Last time it bounced off the fuse mailing list. > > On Thu, Apr 7, 2016 at 5:18 PM, Ashish Sangwan > wrote: >> Wh

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

*ping* Last time it bounced off the fuse mailing list. On Thu, Apr 7, 2016 at 5:18 PM, Ashish Sangwan <ashishsangw...@gmail.com> wrote: > While sending the blocking directIO in fuse, the write request is broken > into sub-requests, each of default size 128k and all the requests are s

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

*ping* Last time it bounced off the fuse mailing list. On Thu, Apr 7, 2016 at 5:18 PM, Ashish Sangwan wrote: > While sending the blocking directIO in fuse, the write request is broken > into sub-requests, each of default size 128k and all the requests are sent > in non-blocking backgr

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On Tue, Apr 12, 2016 at 5:54 AM, Tejun Heo wrote: > Hello, > > On Mon, Apr 11, 2016 at 10:04:42AM +0200, Jakob Unterwurzacher wrote: >> What seems to be happening in the kernel is that the estimated device >> bandwith >> drops to zero. I'm not even sure how this works for FUSE,

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On Tue, Apr 12, 2016 at 5:54 AM, Tejun Heo wrote: > Hello, > > On Mon, Apr 11, 2016 at 10:04:42AM +0200, Jakob Unterwurzacher wrote: >> What seems to be happening in the kernel is that the estimated device >> bandwith >> drops to zero. I'm not even sure how this works for FUSE, but that's what I

[PATCH] FUSE: Improve aio directIO write performance for size extending writes.

changes the size extending aio dio behavior to exactly follow blocking dio. For multi threaded fuse implementation having 10 threads and using buffer size of 64MB to perform async directIO, we are getting double the speed. Signed-off-by: Ashish Sangwan <ashishsangw...@gmail.com> --- fs/fuse/

[PATCH] FUSE: Improve aio directIO write performance for size extending writes.

changes the size extending aio dio behavior to exactly follow blocking dio. For multi threaded fuse implementation having 10 threads and using buffer size of 64MB to perform async directIO, we are getting double the speed. Signed-off-by: Ashish Sangwan --- fs/fuse/file.c | 16 fs

Re: [PATCH] driver core: access dev->driver under dev->mutex in dev_uevent

On Thu, Jan 15, 2015 at 2:16 AM, Greg Kroah-Hartman wrote: > On Wed, Jan 14, 2015 at 11:40:54PM +0530, ashishsangw...@gmail.com wrote: >> From: Ashish Sangwan >> >> We have hit a race condition while parallely accessing device's uevent >> and rmmoding device's dr

Re: [PATCH] driver core: access dev-driver under dev-mutex in dev_uevent

On Thu, Jan 15, 2015 at 2:16 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Wed, Jan 14, 2015 at 11:40:54PM +0530, ashishsangw...@gmail.com wrote: From: Ashish Sangwan a.sang...@samsung.com We have hit a race condition while parallely accessing device's uevent and rmmoding

Re: Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

, BSYM(1f) movne pc, r5 1: get_thread_info tsk b ret_slow_syscall ENDPROC(ret_from_fork) Is this a real issue? Because we are getting this just for static binaries. On Mon, Jul 8, 2013 at 10:46 AM, Ashish Sangwan wrote: > Forget to mention, we are using ARM > > On

Re: Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

, BSYM(1f) movne pc, r5 1: get_thread_info tsk b ret_slow_syscall ENDPROC(ret_from_fork) Is this a real issue? Because we are getting this just for static binaries. On Mon, Jul 8, 2013 at 10:46 AM, Ashish Sangwan ashishsangw...@gmail.com wrote: Forget to mention, we

Re: Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

Forget to mention, we are using ARM On Mon, Jul 8, 2013 at 10:45 AM, Ashish Sangwan wrote: > On kernel version 3.8.13, when we try to execute a statically compiled > binary from kernel, it is giving segfault: > > insmod /mnt/module2.ko > [ 35.56] sample.static: unhandled

Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

On kernel version 3.8.13, when we try to execute a statically compiled binary from kernel, it is giving segfault: insmod /mnt/module2.ko [ 35.56] sample.static: unhandled page fault (11) at 0x, code 0x8007 [ 36.44] Pid: 257, comm:sample.static [ 36.444000] CPU: 3

Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

On kernel version 3.8.13, when we try to execute a statically compiled binary from kernel, it is giving segfault: insmod /mnt/module2.ko [ 35.56] sample.static: unhandled page fault (11) at 0x, code 0x8007 [ 36.44] Pid: 257, comm:sample.static [ 36.444000] CPU: 3

Re: Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper

Forget to mention, we are using ARM On Mon, Jul 8, 2013 at 10:45 AM, Ashish Sangwan ashishsangw...@gmail.com wrote: On kernel version 3.8.13, when we try to execute a statically compiled binary from kernel, it is giving segfault: insmod /mnt/module2.ko [ 35.56] sample.static: unhandled

Re: [PATCH, RFC] Ext4: Mount partition as read only if during orphan cleanup truncate fails to obtain journal handle.

On Thu, Dec 6, 2012 at 10:39 PM, Theodore Ts'o wrote: > On Thu, Dec 06, 2012 at 04:59:43PM +0530, Ashish Sangwan wrote: >> >> Did you get any time to look into this patch? >> This problem is with ext4 only as ext4_truncate does not clean the >> orphan list unlike that o

Re: [PATCH, RFC] Ext4: Mount partition as read only if during orphan cleanup truncate fails to obtain journal handle.

On Thu, Dec 6, 2012 at 10:39 PM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Dec 06, 2012 at 04:59:43PM +0530, Ashish Sangwan wrote: Did you get any time to look into this patch? This problem is with ext4 only as ext4_truncate does not clean the orphan list unlike that of ext3_truncate

Re: [PATCH, RFC] Ext4: Mount partition as read only if during orphan cleanup truncate fails to obtain journal handle.

is not called via ext4_setattr and hence the problem. What do you think? On Fri, Oct 26, 2012 at 5:11 PM, Namjae Jeon wrote: > Add Cc in mail loop. > > Thanks. > > 2012/10/24, Ashish Sangwan : >> During orphan cleanup while doing truncate, if we fail to obtain journal >> handle, t

Re: [PATCH, RFC] Ext4: Mount partition as read only if during orphan cleanup truncate fails to obtain journal handle.

is not called via ext4_setattr and hence the problem. What do you think? On Fri, Oct 26, 2012 at 5:11 PM, Namjae Jeon linkinj...@gmail.com wrote: Add Cc in mail loop. Thanks. 2012/10/24, Ashish Sangwan ashishsangw...@gmail.com: During orphan cleanup while doing truncate, if we fail to obtain journal

Re: [PATCH] UDF: During mount free lvid_bh before rescanning with different blocksize

Hi Jan, > Yeah, I don't think this happens in practice but in theory it could. BTW, > did you check whether we don't need to free other information (like VAT > inode etc.) when rescanning the filesystem? I think we do but currently I'm > catching up after a long vacation and this doesn't have

Re: [PATCH] UDF: During mount free lvid_bh before rescanning with different blocksize

Hi Jan, Yeah, I don't think this happens in practice but in theory it could. BTW, did you check whether we don't need to free other information (like VAT inode etc.) when rescanning the filesystem? I think we do but currently I'm catching up after a long vacation and this doesn't have high

Re: [PATCH] ext4: add error handling when discard cmd is fail in FITRIM

>> How about instead of propagating the error to user and breaking out of >> the discard, just print a warning message like: >> ext4_warning(sb, "error %d while trimming group block from %d to >> %d\n",ret, start, next); > > That's what I said. I think that those errors should be logged, but > I

Re: [PATCH] ext4: add error handling when discard cmd is fail in FITRIM

How about instead of propagating the error to user and breaking out of the discard, just print a warning message like: ext4_warning(sb, error %d while trimming group block from %d to %d\n,ret, start, next); That's what I said. I think that those errors should be logged, but I am not sure

Re: [PATCH] ext4: add error handling when discard cmd is fail in FITRIM

On Mon, Jul 30, 2012 at 5:01 PM, Lukáš Czerner wrote: > On Sun, 29 Jul 2012, Namjae Jeon wrote: > >> Date: Sun, 29 Jul 2012 07:31:54 -0400 >> From: Namjae Jeon >> To: ty...@mit.edu, sand...@redhat.com, lczer...@redhat.com, >> linux-e...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org,

Re: [PATCH] ext4: add error handling when discard cmd is fail in FITRIM

On Mon, Jul 30, 2012 at 5:01 PM, Lukáš Czerner lczer...@redhat.com wrote: On Sun, 29 Jul 2012, Namjae Jeon wrote: Date: Sun, 29 Jul 2012 07:31:54 -0400 From: Namjae Jeon linkinj...@gmail.com To: ty...@mit.edu, sand...@redhat.com, lczer...@redhat.com, linux-e...@vger.kernel.org Cc:

[PATCH RESEND] Ext4: No need to add inode to orphan list during hole punch

While performing punch hole for an inode, i_disksize is not changed. So, there is no need to add the inode to orphan list. Signed-off-by: Ashish Sangwan Signed-off-by: Namjae Jeon --- fs/ext4/extents.c |4 1 file changed, 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4

[PATCH] Ext4: No need to add inode to orphan list during hole punch

Signed-off-by: Ashish Sangwan Signed-off-by: Namjae Jeon --- fs/ext4/extents.c |4 1 file changed, 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 91341ec..3e902f9 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4801,9 +4801,6 @@ int

[PATCH] Ext4: No need to add inode to orphan list during hole punch

Signed-off-by: Ashish Sangwan ashish.sangw...@gmail.com Signed-off-by: Namjae Jeon linkinj...@gmail.com --- fs/ext4/extents.c |4 1 file changed, 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 91341ec..3e902f9 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4

[PATCH RESEND] Ext4: No need to add inode to orphan list during hole punch

While performing punch hole for an inode, i_disksize is not changed. So, there is no need to add the inode to orphan list. Signed-off-by: Ashish Sangwan ashish.sangw...@gmail.com Signed-off-by: Namjae Jeon linkinj...@gmail.com --- fs/ext4/extents.c |4 1 file changed, 4 deletions

[PATCH] UDF: During mount free lvid_bh before rescanning with different blocksize

If s_lvid_bh is not freed and set to NULL before re-scanning partition with default block size, we might end up using wrong lvid in case s_lvid_bh is not updated in udf_load_logicalvolint during rescan. Signed-off-by: Ashish Sangwan Signed-off-by: Namjae Jeon --- fs/udf/super.c |2 ++ 1

[PATCH] UDF: During mount free lvid_bh before rescanning with different blocksize

If s_lvid_bh is not freed and set to NULL before re-scanning partition with default block size, we might end up using wrong lvid in case s_lvid_bh is not updated in udf_load_logicalvolint during rescan. Signed-off-by: Ashish Sangwan ashish.sangw...@gmail.com Signed-off-by: Namjae Jeon linkinj

Re: [PATCH v3] ext4: fix hole punch failure when depth is greater than 0

Hi Ted, Did you get time to check this patch? If possible, can you collect the patch from the last sent mail? On Tue, Jul 10, 2012 at 9:56 PM, Ashish Sangwan wrote: > Whether to continue removing extents or not is decided by the return value > of function ext4_ext_more_to_rm() which ch

Re: [PATCH v3] ext4: fix hole punch failure when depth is greater than 0

Hi Ted, Did you get time to check this patch? If possible, can you collect the patch from the last sent mail? On Tue, Jul 10, 2012 at 9:56 PM, Ashish Sangwan ashishsangw...@gmail.com wrote: Whether to continue removing extents or not is decided by the return value of function

[PATCH v3] ext4: fix hole punch failure when depth is greater than 0

the above mentioned problem as instead of removing the extents from the end of file, it starts removing the blocks from the particular extent from which removing blocks is actually required and continue backward until done. Signed-off-by: Ashish Sangwan Signed-off-by: Namjae Jeon Reviewed-by: Lu

[PATCH v3] ext4: fix hole punch failure when depth is greater than 0

problem as instead of removing the extents from the end of file, it starts removing the blocks from the particular extent from which removing blocks is actually required and continue backward until done. Signed-off-by: Ashish Sangwan ashish.sangw...@gmail.com Signed-off-by: Namjae Jeon linkinj

Re: [PATCH v3] ext4: fix hole punch failure when depth is greater than 0

Please ignore the last sent mail. I will re-send the patch in new mail chain. Thanks, Ashish On Tue, Jul 10, 2012 at 6:13 AM, Ashish Sangwan wrote: > Whether to continue removing extents or not is decided by the return value > of function ext4_ext_more_to_rm() which checks 2 cond

[PATCH v3] ext4: fix hole punch failure when depth is greater than 0

the above mentioned problem as instead of removing the extents from the end of file, it starts removing the blocks from the particular extent from which removing blocks is actually required and continue backward until done. Signed-off-by: Ashish Sangwan Signed-off-by: Namjae Jeon Reviewed-by: Lu

Re: [PATCH v2] ext4: fix hole punch failure when depth is greater than 0

> Ok, the code is not very clear, but now I can see it. p_block is > actually misused here to store the number of indexes in the current > node while diving into the tree. Then on the way up, we are checking > that to see if the eh_entries changed or not (which is indicating > that something has

Re: [PATCH v2] ext4: fix hole punch failure when depth is greater than 0

Ok, the code is not very clear, but now I can see it. p_block is actually misused here to store the number of indexes in the current node while diving into the tree. Then on the way up, we are checking that to see if the eh_entries changed or not (which is indicating that something has been

[PATCH v3] ext4: fix hole punch failure when depth is greater than 0

problem as instead of removing the extents from the end of file, it starts removing the blocks from the particular extent from which removing blocks is actually required and continue backward until done. Signed-off-by: Ashish Sangwan ashish.sangw...@gmail.com Signed-off-by: Namjae Jeon linkinj

Re: [PATCH v3] ext4: fix hole punch failure when depth is greater than 0

Please ignore the last sent mail. I will re-send the patch in new mail chain. Thanks, Ashish On Tue, Jul 10, 2012 at 6:13 AM, Ashish Sangwan ashishsangw...@gmail.com wrote: Whether to continue removing extents or not is decided by the return value of function ext4_ext_more_to_rm() which checks