similar to: [RFC] add support for fallocate()

Hi all, I'm trying to compile rsync from the git sources (rev 8bcd6a4afff3cb8197d5589ec4fdf9fe153f53de) the configuration step went without any reported problems so I ran the make utility to compile the code base. The following error was almost immediately returned after running make: ./rsync.h:669:26: fatal error: linux/falloc.h: No such file or directory The reported line resides in

On 5/31/23 4:29 PM, Lu?s Henriques wrote: > Joseph Qi <joseph.qi at linux.alibaba.com> writes: > >> On 5/29/23 11:26 PM, Lu?s Henriques wrote: >>> When changing a file size with fallocate() the new size isn't being >>> checked. In particular, the FSIZE ulimit isn't being checked, which makes >>> fstest generic/228 fail. Simply adding a call

This is a note to let you know that I've just added the patch titled ocfs2: check new file size on fallocate call to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-check-new-file-size-on-fallocate-call.patch and it can be found in the queue-4.14 subdirectory. If

This is a note to let you know that I've just added the patch titled ocfs2: check new file size on fallocate call to the 4.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-check-new-file-size-on-fallocate-call.patch and it can be found in the queue-4.19 subdirectory. If

This is a note to let you know that I've just added the patch titled ocfs2: check new file size on fallocate call to the 5.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-check-new-file-size-on-fallocate-call.patch and it can be found in the queue-5.4 subdirectory. If you,

This is a note to let you know that I've just added the patch titled ocfs2: check new file size on fallocate call to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-check-new-file-size-on-fallocate-call.patch and it can be found in the queue-5.10 subdirectory. If

This is a note to let you know that I've just added the patch titled ocfs2: check new file size on fallocate call to the 5.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-check-new-file-size-on-fallocate-call.patch and it can be found in the queue-5.15 subdirectory. If

This is a note to let you know that I've just added the patch titled ocfs2: check new file size on fallocate call to the 6.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-check-new-file-size-on-fallocate-call.patch and it can be found in the queue-6.1 subdirectory. If you,

This is a note to let you know that I've just added the patch titled ocfs2: check new file size on fallocate call to the 6.3-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-check-new-file-size-on-fallocate-call.patch and it can be found in the queue-6.3 subdirectory. If you,

The patch titled Subject: ocfs2: check new file size on fallocate call has been added to the -mm mm-nonmm-unstable branch. Its filename is ocfs2-check-new-file-size-on-fallocate-call.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/ocfs2-check-new-file-size-on-fallocate-call.patch This patch will later appear in

When using file systems not supporting ZERO_RANGE (e.g. NFS 4.2) or block device on kernel < 4.9, we used to call fallocate() for every zero, fail with EOPNOTSUPP, and fallback to manual zeroing. When trimming, we used to try unsupported fallocate() on every call. Change file handle to remember if punching holes or zeroing range are supported, and avoid unsupported calls. - zero changed to:

When using file systems not supporting ZERO_RANGE (e.g. NFS 4.2) or block device on kernel < 4.9, we used to call fallocate() for every zero, fail with EOPNOTSUPP, and fallback to manual zeroing. When trimming, we used to try unsupported fallocate() on every call. Change file handle to remember if punching holes or zeroing range are supported, and avoid unsupported calls. - zero changed to:

When using file systems not supporting ZERO_RANGE (e.g. NFS 4.2) or block device on kernel < 4.9, we used to call fallocate() for every zero, fail with EOPNOTSUPP, and fallback to manual zeroing. When trimming, we used to try unsupported fallocate() on every call. Change file handle to remember if punching holes or zeroing range are supported, and avoid unsupported calls. - zero changed to:

When using file systems not supporting ZERO_RANGE (e.g. NFS 4.2) or block device on kernel < 4.9, we used to call fallocate() for every zero, fail with EOPNOTSUPP, and fallback to manual zeroing. When trimming, we used to try unsupported fallocate() on every call. Change file handle to remember if punching holes or zeroing range are supported, and avoid unsupported calls. - can_trim changed

On 5/29/23 11:26 PM, Lu?s Henriques wrote: > When changing a file size with fallocate() the new size isn't being > checked. In particular, the FSIZE ulimit isn't being checked, which makes > fstest generic/228 fail. Simply adding a call to inode_newsize_ok() fixes > this issue. > > Signed-off-by: Lu?s Henriques <lhenriques at suse.de> > --- >

When changing a file size with fallocate() the new size isn't being checked. In particular, the FSIZE ulimit isn't being checked, which makes fstest generic/228 fail. Simply adding a call to inode_newsize_ok() fixes this issue. Signed-off-by: Lu?s Henriques <lhenriques at suse.de> --- fs/ocfs2/file.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

fallocate(2) may allocate large number of file extents, so it''s not good to do it in a single transaction. This patch make fallocate(2) start a new transaction for each file extents it allocates. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 6/fs/btrfs/inode.c 7/fs/btrfs/inode.c --- 6/fs/btrfs/inode.c 2009-11-02 10:47:16.106890431 +0800 +++ 7/fs/btrfs/inode.c

On Thu, Aug 2, 2018 at 10:30 PM Eric Blake <eblake@redhat.com> wrote: > On 08/02/2018 02:05 PM, Nir Soffer wrote: > > When using file systems not supporting ZERO_RANGE (e.g. NFS 4.2) or > > block device on kernel < 4.9, we used to call fallocate() for every > > zero, fail with EOPNOTSUPP, and fallback to manual zeroing. When > > trimming, we used to try

The argument passed to do_punch_hole is a OFF_T to beginning with, and otherwise holes bigger than 2G will cause rsync to fail. --- syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/syscall.c b/syscall.c index e1a02a3c..e8ce7d5c 100644 --- a/syscall.c +++ b/syscall.c @@ -523,7 +523,7 @@ OFF_T do_fallocate(int fd, OFF_T offset, OFF_T length) /* Punch a hole at pos

Even though we allocate more, we should be updating inode i_size as per the arguments passed Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- Changes from V1: We should update i_size only if actual_len and cur_offset are both larger than i_size. Otherwise if actual_len is < i_size and cur_offset > i_size we may end up setting wrong i_size value