similar to: It may be an ocfs2 bug.

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

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> > --- >

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

Provide a splice_read stub for ocfs2. This emits trace lines and does an atime lock/update before calling filemap_splice_read(). It doesn't do this for around direct_splice_read() as that will call ->read_iter(). A couple of new tracepoints are added for this purpose. Signed-off-by: David Howells <dhowells at redhat.com> cc: Christoph Hellwig <hch at lst.de> cc: Al Viro

Provide a splice_read stub for ocfs2. This emits trace lines and does an atime lock/update before calling filemap_splice_read(). Splicing from direct I/O is handled by the caller. A couple of new tracepoints are added for this purpose. Signed-off-by: David Howells <dhowells at redhat.com> cc: Christoph Hellwig <hch at lst.de> cc: Al Viro <viro at zeniv.linux.org.uk> cc: Jens

Hi all, As we have test the OCFS2, and create one image file to be used as one virtual machine's disk, it size is more than 2T, but its stats information is error. Is file size limited to 2T? Or any other way to avoid its? Thanks -------------------------------------------------------------------------------------------------------------------------------------

Hi all, As we have test the OCFS2, and create one image file to be used as one virtual machine's disk, it size is more than 2T, but its stats information is error. Is file size limited to 2T? Or any other way to avoid its? Thanks -------------------------------------------------------------------------------------------------------------------------------------

As we test the ocfs2 cluster, the cluster is sometime hangs up. I got some information about the dead lock, which cause the cluster hangs up, the sys dir / lock is held and the node did not release it which cause the cluster hangs up. root at cvknode-21:~# ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN | grep D PID STAT COMMAND WIDE-WCHAN-COLUMN 7489 D jbd2/sdh-621

As we test the ocfs2 cluster, the cluster is sometime hangs up. I got some information about the dead lock, which cause the cluster hangs up, the sys dir / lock is held and the node did not release it which cause the cluster hangs up. root at cvknode-21:~# ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN | grep D PID STAT COMMAND WIDE-WCHAN-COLUMN 7489 D jbd2/sdh-621

We're currently support two paths from VFS to preallocate unwritten extents(from FS_IOC_RESVSP, or fallocate()), likewise, behavior of punching-hole should be treated as the same, this patch tries to teach file_ioctl() to handle FS_IOC_UNRESVSP, underlying filesystem like ocfs2 is wise enough to do the rest of work;-) Signed-off-by: Tristan Ye <tristan.ye at oracle.com> --- fs/ioctl.c

We're currently support two paths from VFS to preallocate unwritten extents(from FS_IOC_RESVSP, or fallocate()), likewise, behavior of punching-hole should be treated as the same, this patch tries to teach file_ioctl() to handle FS_IOC_UNRESVSP, underlying filesystem like ocfs2 is wise enough to do the rest of work;-) Signed-off-by: Tristan Ye <tristan.ye at oracle.com> --- fs/ioctl.c

Hi All: As we test with two node in one OCFS2 cluster. The cluster is hang up may be for dead lock. We use the debugfs.ocfs tool founding that one resource is holding by one node who has it for long time and another node can still wait for the resource. So the cluster is hang up. debugfs.ocfs2 -R "fs_locks -B" /dev/dm-0 debugfs.ocfs2 -R "dlm_locks LOCKID_XXX" /dev/dm-0 How