2024-05-05 07:24:56 |
Nick O'Connor |
bug |
|
|
added bug |
2024-05-05 07:29:45 |
Nick O'Connor |
description |
GlusterFS version 11.1 contains a recursion bug which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/issues/4295, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this issue since it results in possible data loss or corruption depending on the users' configuration and timing of brick crashes. |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this issue since it results in possible data loss or corruption depending on the users' configuration and timing of brick crashes. I've asked the GlusterFS maintainers to cut new release with the fix. |
|
2024-05-05 07:29:58 |
Nick O'Connor |
description |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this issue since it results in possible data loss or corruption depending on the users' configuration and timing of brick crashes. I've asked the GlusterFS maintainers to cut new release with the fix. |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this issue since it results in possible data loss or corruption depending on the users' configuration and timing of brick crashes. I've also asked the GlusterFS maintainers to cut new release with the fix. |
|
2024-05-05 07:31:48 |
Nick O'Connor |
description |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this issue since it results in possible data loss or corruption depending on the users' configuration and timing of brick crashes. I've also asked the GlusterFS maintainers to cut new release with the fix. |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this issue since it results in possible data loss or corruption depending on the user's configuration and timing of brick crashes. I've also asked the GlusterFS maintainers to cut new release with the fix. |
|
2024-05-07 06:27:26 |
Nick O'Connor |
description |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this issue since it results in possible data loss or corruption depending on the user's configuration and timing of brick crashes. I've also asked the GlusterFS maintainers to cut new release with the fix. |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this since it results in possible data loss or corruption depending on the user's configuration and timing of brick crashes. I've asked the GlusterFS maintainers to cut new release with the fix but it's unclear when that may be done. |
|
2024-05-08 13:40:35 |
Athos Ribeiro |
nominated for series |
|
Ubuntu Noble |
|
2024-05-08 13:40:35 |
Athos Ribeiro |
bug task added |
|
glusterfs (Ubuntu Noble) |
|
2024-05-08 13:40:35 |
Athos Ribeiro |
nominated for series |
|
Ubuntu Oracular |
|
2024-05-08 13:40:35 |
Athos Ribeiro |
bug task added |
|
glusterfs (Ubuntu Oracular) |
|
2024-05-08 13:40:45 |
Athos Ribeiro |
glusterfs (Ubuntu Oracular): status |
New |
Triaged |
|
2024-05-08 13:40:49 |
Athos Ribeiro |
glusterfs (Ubuntu Noble): status |
New |
Triaged |
|
2024-05-08 13:41:00 |
Athos Ribeiro |
tags |
|
server-todo |
|
2024-05-08 13:41:09 |
Athos Ribeiro |
bug |
|
|
added subscriber Ubuntu Server |
2024-05-08 20:04:37 |
Nick O'Connor |
description |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this since it results in possible data loss or corruption depending on the user's configuration and timing of brick crashes. I've asked the GlusterFS maintainers to cut new release with the fix but it's unclear when that may be done. |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix has yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this since it results in possible data loss or corruption depending on the user's configuration and timing of brick crashes. I've asked the GlusterFS maintainers to cut new release with the fix but it's unclear when that may be done. |
|
2024-05-09 00:37:44 |
Nick O'Connor |
description |
GlusterFS version 11.1 contains a recursion bug (https://github.com/gluster/glusterfs/issues/4295) which results in bricks SEGFAULTing. The issue was fixed upstream by https://github.com/gluster/glusterfs/pull/4302, but the fix has yet to be included in a release. I encountered this issue when upgrading from 22.04 to 24.04 (https://github.com/gluster/glusterfs/issues/4085#issuecomment-2094525275).
I think a patch should be considered for this since it results in possible data loss or corruption depending on the user's configuration and timing of brick crashes. I've asked the GlusterFS maintainers to cut new release with the fix but it's unclear when that may be done. |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to `inode_unref` when a namespaced inode is destroyed.
[ Test Plan ]
* The triggers for the issue are not well understood. I have compiled the patch into version 11.1-4build3 of glusterfs and it resolved the issue on my system.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy (private function) did not call inode_unref (public function) before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
|
2024-05-09 01:21:58 |
Nick O'Connor |
description |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to `inode_unref` when a namespaced inode is destroyed.
[ Test Plan ]
* The triggers for the issue are not well understood. I have compiled the patch into version 11.1-4build3 of glusterfs and it resolved the issue on my system.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy (private function) did not call inode_unref (public function) before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* The triggers for the issue are not well understood. I have compiled the patch into version 11.1-4build3 of glusterfs and it resolved the issue on my system.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy (private function) did not call inode_unref (public function) before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
|
2024-05-10 18:02:11 |
Nick O'Connor |
attachment added |
|
fix-stack-overflow-in-inode-destroy.debdiff https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843/+attachment/5777077/+files/fix-stack-overflow-in-inode-destroy.debdiff |
|
2024-05-10 18:03:25 |
Nick O'Connor |
bug |
|
|
added subscriber Ubuntu Sponsors |
2024-05-10 18:07:57 |
Nick O'Connor |
attachment added |
|
fix-stack-overflow-in-inode-destroy.debdiff https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843/+attachment/5777078/+files/fix-stack-overflow-in-inode-destroy.debdiff |
|
2024-05-10 18:08:28 |
Nick O'Connor |
attachment removed |
fix-stack-overflow-in-inode-destroy.debdiff https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843/+attachment/5777077/+files/fix-stack-overflow-in-inode-destroy.debdiff |
|
|
2024-05-10 18:13:31 |
Nick O'Connor |
description |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* The triggers for the issue are not well understood. I have compiled the patch into version 11.1-4build3 of glusterfs and it resolved the issue on my system.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy (private function) did not call inode_unref (public function) before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* The triggers for the issue are not well understood. I have compiled the patch against version 11.1-4build3 of glusterfs and it resolved the issue on my system.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
|
2024-05-10 18:37:31 |
Nick O'Connor |
glusterfs (Ubuntu Noble): status |
Triaged |
In Progress |
|
2024-05-10 18:37:31 |
Nick O'Connor |
glusterfs (Ubuntu Noble): assignee |
|
Nick O'Connor (nick-oconnor) |
|
2024-05-16 06:13:38 |
Nick O'Connor |
summary |
Gluster 11.1 brick SEGFAULT |
Brick SEGFAULTs in 11.1 |
|
2024-05-16 08:08:01 |
Nick O'Connor |
attachment added |
|
fix-stack-overflow-in-inode-destroy.debdiff https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843/+attachment/5778934/+files/fix-stack-overflow-in-inode-destroy.debdiff |
|
2024-05-16 08:08:14 |
Nick O'Connor |
attachment added |
|
fix-stack-overflow-in-inode-destroy.debdiff https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843/+attachment/5778935/+files/fix-stack-overflow-in-inode-destroy.debdiff |
|
2024-05-16 08:08:45 |
Nick O'Connor |
attachment removed |
fix-stack-overflow-in-inode-destroy.debdiff https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843/+attachment/5777078/+files/fix-stack-overflow-in-inode-destroy.debdiff |
|
|
2024-05-16 08:08:52 |
Nick O'Connor |
attachment removed |
fix-stack-overflow-in-inode-destroy.debdiff https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843/+attachment/5778934/+files/fix-stack-overflow-in-inode-destroy.debdiff |
|
|
2024-05-17 16:53:06 |
Nick O'Connor |
glusterfs (Ubuntu Noble): assignee |
Nick O'Connor (nick-oconnor) |
|
|
2024-05-22 15:11:23 |
Athos Ribeiro |
glusterfs (Ubuntu Oracular): assignee |
|
Athos Ribeiro (athos-ribeiro) |
|
2024-05-22 15:11:26 |
Athos Ribeiro |
glusterfs (Ubuntu Noble): assignee |
|
Athos Ribeiro (athos-ribeiro) |
|
2024-06-07 04:25:37 |
Bryce Harrington |
glusterfs (Ubuntu Oracular): assignee |
Athos Ribeiro (athos-ribeiro) |
Bryce Harrington (bryce) |
|
2024-06-07 04:25:39 |
Bryce Harrington |
glusterfs (Ubuntu Noble): assignee |
Athos Ribeiro (athos-ribeiro) |
Bryce Harrington (bryce) |
|
2024-06-12 07:25:31 |
Bryce Harrington |
glusterfs (Ubuntu Oracular): status |
Triaged |
Fix Committed |
|
2024-06-12 07:25:41 |
Bryce Harrington |
glusterfs (Ubuntu Noble): status |
In Progress |
Confirmed |
|
2024-06-12 07:43:41 |
Bryce Harrington |
removed subscriber Ubuntu Sponsors |
|
|
|
2024-06-12 07:44:39 |
Bryce Harrington |
glusterfs (Ubuntu Noble): status |
Confirmed |
Fix Committed |
|
2024-06-13 00:07:36 |
Launchpad Janitor |
glusterfs (Ubuntu Oracular): status |
Fix Committed |
Fix Released |
|
2024-06-14 14:27:05 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
2024-06-14 14:39:15 |
Andreas Hasenack |
glusterfs (Ubuntu Noble): status |
Fix Committed |
Incomplete |
|
2024-06-14 18:36:38 |
Nick O'Connor |
description |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* The triggers for the issue are not well understood. I have compiled the patch against version 11.1-4build3 of glusterfs and it resolved the issue on my system.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* I experienced brick crashes on specific volumes about once per hour. On my system, this issue only impacted a locally mounted volume backing a Minio instance (an S3 API compatible server) used by Restic clients (an incremental backup system with lots of small file creations and deletions). Other volumes served with NFS Ganesha with primarily large file random access never triggered it.
* I attempted to replicate the workload by running various file system benchmarking tools within their own user namespace (i.e. lots of small file creations and deletion) but was not able to replicate the crash.
* I've been running the proposed patch since 2024-05-06 and haven't experienced a single crash.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
|
2024-06-14 20:59:11 |
Andreas Hasenack |
description |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* I experienced brick crashes on specific volumes about once per hour. On my system, this issue only impacted a locally mounted volume backing a Minio instance (an S3 API compatible server) used by Restic clients (an incremental backup system with lots of small file creations and deletions). Other volumes served with NFS Ganesha with primarily large file random access never triggered it.
* I attempted to replicate the workload by running various file system benchmarking tools within their own user namespace (i.e. lots of small file creations and deletion) but was not able to replicate the crash.
* I've been running the proposed patch since 2024-05-06 and haven't experienced a single crash.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* I experienced brick crashes on specific volumes about once per hour. On my system, this issue only impacted a locally mounted volume backing a Minio instance (an S3 API compatible server) used by Restic clients (an incremental backup system with lots of small file creations and deletions). Other volumes served with NFS Ganesha with primarily large file random access never triggered it.
* I attempted to replicate the workload by running various file system benchmarking tools within their own user namespace (i.e. lots of small file creations and deletion) but was not able to replicate the crash.
* I've been running the proposed patch since 2024-05-06 and haven't experienced a single crash.
Therefore, the test plan is to run the packages from proposed for at least a day, under the same load as when the bug happened, and confirm that the crashes reported in this bug no longer happen.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
|
2024-06-14 21:08:49 |
Andreas Hasenack |
glusterfs (Ubuntu Noble): status |
Incomplete |
Fix Committed |
|
2024-06-14 21:08:50 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2024-06-14 21:09:20 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
2024-06-14 21:09:26 |
Andreas Hasenack |
tags |
server-todo |
server-todo verification-needed verification-needed-noble |
|
2024-06-17 17:41:48 |
Nick O'Connor |
description |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* I experienced brick crashes on specific volumes about once per hour. On my system, this issue only impacted a locally mounted volume backing a Minio instance (an S3 API compatible server) used by Restic clients (an incremental backup system with lots of small file creations and deletions). Other volumes served with NFS Ganesha with primarily large file random access never triggered it.
* I attempted to replicate the workload by running various file system benchmarking tools within their own user namespace (i.e. lots of small file creations and deletion) but was not able to replicate the crash.
* I've been running the proposed patch since 2024-05-06 and haven't experienced a single crash.
Therefore, the test plan is to run the packages from proposed for at least a day, under the same load as when the bug happened, and confirm that the crashes reported in this bug no longer happen.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* I experienced brick crashes on specific volumes about once per hour. On my system, this issue only impacted a locally mounted volume backing a Minio instance (an S3 API compatible server) used by Restic clients (an incremental backup system with lots of small file creations and deletions). Other volumes served with NFS Ganesha with primarily large file random access never triggered it.
* I attempted to replicate the workload by running various file system benchmarking tools within their own user namespace (i.e. lots of small file creations and deletion) but was not able to replicate the crash.
* I've been running the proposed patch since 2024-05-06 and haven't experienced a single crash.
* The test plan is to run the packages from proposed for at least a day, under the same load as when the bug happened, and confirm that the crashes reported in this bug no longer happen.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
|
2024-06-17 17:42:49 |
Nick O'Connor |
description |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* I experienced brick crashes on specific volumes about once per hour. On my system, this issue only impacted a locally mounted volume backing a Minio instance (an S3 API compatible server) used by Restic clients (an incremental backup system with lots of small file creations and deletions). Other volumes served with NFS Ganesha with primarily large file random access never triggered it.
* I attempted to replicate the workload by running various file system benchmarking tools within their own user namespace (i.e. lots of small file creations and deletion) but was not able to replicate the crash.
* I've been running the proposed patch since 2024-05-06 and haven't experienced a single crash.
* The test plan is to run the packages from proposed for at least a day, under the same load as when the bug happened, and confirm that the crashes reported in this bug no longer happen.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
[ Impact ]
* Users experience brick SEGFAULTs under certain not-yet-understood scenarios. Some reports include a high percentage of small file I/O. I encountered the issue roughly every hour with Minio backed by GlusterFS on ZFS.
* This bug introduces an increased risk of data loss or corruption depending on the user's configuration and timing of brick crashes.
* Core dumps from multiple users revealed that the SEGFAULTs are caused by a stack overflow when namespaced inodes are destroyed.
* The patch removes the recursive call to inode_unref when a namespaced inode is destroyed.
[ Test Plan ]
* I experienced brick crashes on specific volumes about once per hour. On my system, this issue only impacted a locally mounted volume backing a Minio instance (an S3 API compatible server) used by Restic clients (an incremental backup system with lots of small file creations and deletions). Other volumes served with NFS Ganesha with primarily large file random access never triggered it.
* I attempted to replicate the workload by running various file system benchmarking tools within their own user namespace (i.e. lots of small file creations and deletion) but was not able to replicate the crash.
* I've been running the proposed patch since 2024-05-06 and haven't experienced a single crash.
* The test plan is to run the packages from proposed for at least a day, under the same load as when the bug happened, and confirm that the crashes reported in this bug no longer happen.
[ Where problems could occur ]
* It's conceivable that this patch introduces undesired behavior when inodes are destroyed, however I highly doubt this scenario as __inode_destroy was not recursive before the change which introduced the bug.
[ Other Info ]
* PR which introduced the bug: https://github.com/gluster/glusterfs/pull/1763
* PR which added this patch: https://github.com/gluster/glusterfs/pull/4302
* Issue discussion: https://github.com/gluster/glusterfs/issues/4295 |
|
2024-06-19 15:20:42 |
Christian Ehrhardt |
tags |
server-todo verification-needed verification-needed-noble |
server-todo verification-done verification-done-noble |
|
2024-06-27 14:50:52 |
Launchpad Janitor |
glusterfs (Ubuntu Noble): status |
Fix Committed |
Fix Released |
|
2024-06-27 14:50:59 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2024-07-30 20:50:03 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/glusterfs/+git/glusterfs/+merge/470379 |
|
2024-07-30 20:55:24 |
Andreas Hasenack |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/glusterfs/+git/glusterfs/+merge/470379 |
|
|
2024-07-30 21:04:18 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/glusterfs/+git/glusterfs/+merge/470379 |
|