similar to: [PATCH] Remove redundant BUG_ON in __dlm_queue_ast

The versioning information is confusing for end-users. The numbers are stuck at 1.5.0 when the tools have moved to 1.8.3. I suggest removing the versioning system in the kernel altogether and let the kernel version be the guide to debug issues. However, if you think versioning is still required, please state the reason and modify the version string in the ver.* files to reflect the uptodate

Found 15 patches (out of 162) that appeared relevant to ocfs2 1.4. Please review. Sunil

While removing a non-empty directory, the kernel dumps a message: (rmdir,21743,1):ocfs2_unlink:953 ERROR: status = -39 Suppress the error message from being printed in the dmesg so users don't panic. Signed-off-by: Goldwyn Rodrigues <rgoldwyn at suse.com> --- diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c index 04ee1b5..33c7b91 100644 --- a/fs/ocfs2/namei.c +++ b/fs/ocfs2/namei.c @@

Mainline commit d4f7e650e55af6b235871126f747da88600e8040 attempts to delay the dlm_thread from sending the drop ref message if the lockres is being migrated. The problem is that we make the dlm_thread wait for the migration to complete. This causes a deadlock as dlm_thread also participates in the lockres migration process. A better fix for the original oss bugzilla#1012 is in testing.

Linus, et al, Here are all the outstanding ocfs2 fixes for 2.6.31. The major fixes are for aio write and for non-sparse file extending. There are also a couple of b-tree fixes as well as some for quotas. Please pull. Joel The following changes since commit 44b572809581d5a10dbe35aa6bf689f32b9c5ad6: Yinghai Lu (1): x86: don't clear nodes_states[N_NORMAL_MEMORY] when numa is not

generic_write_checks() expects count to be initialized to the size of the write. Writes to files open with O_DIRECT|O_LARGEFILE write 0 bytes because count in uninitialized. Signed-off-by: Goldwyn Rodrigues <rgoldwyn at suse.de> diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index a5887df..5b9c8af 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -1841,6 +1841,7 @@ relock: if (ret)

Signed-off-by: Goldwyn Rodrigues <rgoldwyn at suse.com> --- fs/ocfs2/stack_user.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/stack_user.c b/fs/ocfs2/stack_user.c index 286edf1..1b18193 100644 --- a/fs/ocfs2/stack_user.c +++ b/fs/ocfs2/stack_user.c @@ -799,11 +799,31 @@ static int fs_protocol_compare(struct

On 10/14/2015 03:57 AM, Joseph Qi wrote: > On 2015/10/14 16:45, Zhangguanghui wrote: >> Hi, >> "status = -30" means it has encountered EROFS when start transaction. >> And system panic is because s_mount_opt is set to OCFS2_MOUNT_ERRORS_PANIC in __ocfs2_abort, >> ideal with OCFS2_MOUNT_ERRORS_PANIC first in ocfs2_handle_error. >> so I think that it is

Hi! What are the typical ways to work around the 64 groups limit? thanks klaus

Hi, "status = -30" means it has encountered EROFS when start transaction. And system panic is because s_mount_opt is set to OCFS2_MOUNT_ERRORS_PANIC in __ocfs2_abort, ideal with OCFS2_MOUNT_ERRORS_PANIC first in ocfs2_handle_error. so I think that it is not reasonable, Therefore, this setting shall be canceled in __ocfs2_abort. thanks ________________________________ zhangguanghui

Linus et al, Here are the ocfs2 updates for 2.6.35. There are two major changes. Mark added allocation reservations to our node-local allocators. This gets us much more contiguousness when many processes are growing files in parallel. On the other end of contiguousness, ocfs2 has had a major limitation since the beginning. When ocfs2 needs new inodes, it has always grown its metadata

All, We are pleased to announce the release of OCFS2 1.4.10-1 and OCFS2 tools 1.6.3-2 for Oracle Linux 5 Update 7 and higher and Redhat Enterprise Linux 5 Update 7 and higher. Oracle's Unbreakable Linux Network users who are subscribing to the "OCFS2 1.4 packages for Enterprise Linux 5" channel can upgrade to this release by running up2date. Red Hat's Enterprise Linux 5

Hello list, I have a ~10TB ocfs2 filesystem in a 8-node cluster. This sits on a logical volume (I know lv is not cluster aware, but I make sure no one touches the lv, while the cluster is running). The LV consists of 5x2TB multipath devices. I recently had errors like this on some nodes: OCFS2: ERROR (device dm-7): ocfs2_check_group_descriptor: Group Descriptor # 0 has bad signature File

The following series of patches comprises the bulk of our outstanding changes for Ocfs2. Aside from the usual set of cleanups and fixes that were inappropriate for 2.6.25, there are a few highlights: The '/sys/o2cb' directory has been moved to '/sys/fs/o2cb'. The new location meshes better with modern sysfs layout. A symbolic link has been placed in the old location so as to

The 'disable_cb' callback is designed as an optimization to tell the host we don't need callbacks now. As it is not reliable, the debug check is overzealous: it can happen on two CPUs at the same time. Document this. Even if it were reliable, the virtio_net driver doesn't disable callbacks on transmit so the START_USE/END_USE debugging reentrance protection can be easily tripped

We can just return an error and we''ll bail out properly. We still want to catch this case to make sure we don''t have a bug somewhere, so just warn if this pops up. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 961ae6f..db6e11f

1 / 2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

The 'disable_cb' callback is designed as an optimization to tell the host we don't need callbacks now. As it is not reliable, the debug check is overzealous: it can happen on two CPUs at the same time. Document this. Even if it were reliable, the virtio_net driver doesn't disable callbacks on transmit so the START_USE/END_USE debugging reentrance protection can be easily tripped

On 07/28/2014 12:04 PM, Eduardo Habkost wrote: > When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on > the {rd,wr}msr instructions. This makes serious issues (either on the > guest kernel, or on the host) be silently ignored, and is different from > the native MSR code (which does not ignore the exceptions). > > As paravirt.h already includes linux/bug.h, I

Alexey Lapitsky <lex.public at gmail.com> writes: > Hi, > > I'm hitting this bug with both ext4 and btrfs. > > Here's an example of the backtrace: > https://gist.github.com/vzctl/e888a821333979120932 > > I tried raising this BUG only for direct ring and it solved the problem: > > - BUG_ON(total_sg > vq->vring.num); > +