* [PATCH 0/1] xfs: Use xarray to track SB UUIDs instead of plain array.
@ 2026-01-30 15:42 Lukas Herbolt
2026-01-30 15:42 ` [PATCH] " Lukas Herbolt
0 siblings, 1 reply; 10+ messages in thread
From: Lukas Herbolt @ 2026-01-30 15:42 UTC (permalink / raw)
To: linux-xfs; +Cc: cem, Lukas Herbolt
Hi,
It was discussed in previous thread [1]. Some older kernels (pre v6.12),
complained doing allocation over 2xPAGE_SIZE in krealloc when mounting over
512 unique XFS.
The warning was removed in v6.12, but Christoph suggested to start using
xrarray instead of plain array. So here it is.
[1]
- https://lore.kernel.org/linux-xfs/aPhjZ4sfHngyJRQK@infradead.org/
Lukas Herbolt (1):
xfs: Use xarray to track SB UUIDs instead of plain array.
fs/xfs/xfs_mount.c | 87 +++++++++++++++++++++++-----------------------
fs/xfs/xfs_mount.h | 3 +-
fs/xfs/xfs_super.c | 2 +-
3 files changed, 46 insertions(+), 46 deletions(-)
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
--
2.52.0
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-01-30 15:42 [PATCH 0/1] xfs: Use xarray to track SB UUIDs instead of plain array Lukas Herbolt
@ 2026-01-30 15:42 ` Lukas Herbolt
2026-01-30 16:55 ` Darrick J. Wong
2026-02-02 7:37 ` Christoph Hellwig
0 siblings, 2 replies; 10+ messages in thread
From: Lukas Herbolt @ 2026-01-30 15:42 UTC (permalink / raw)
To: linux-xfs; +Cc: cem, Lukas Herbolt
Removing the plain array to track the UUIDs and switch
xarray to make more readable.
Signed-off-by: Lukas Herbolt <lukas@herbolt.com>
---
fs/xfs/xfs_mount.c | 87 +++++++++++++++++++++++-----------------------
fs/xfs/xfs_mount.h | 3 +-
fs/xfs/xfs_super.c | 2 +-
3 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 0953f6ae94ab..35c0d411e0cb 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -42,18 +42,48 @@
#include "scrub/stats.h"
#include "xfs_zone_alloc.h"
-static DEFINE_MUTEX(xfs_uuid_table_mutex);
-static int xfs_uuid_table_size;
-static uuid_t *xfs_uuid_table;
+static DEFINE_XARRAY_ALLOC(xfs_uuid_table);
+
+/*
+ * Helper fucntions to store UUID in xarray.
+ */
+STATIC int
+xfs_uuid_insert(uuid_t *uuid)
+{
+ uint32_t index = 0;
+
+ return xa_alloc(&xfs_uuid_table, &index, uuid,
+ xa_limit_32b, GFP_KERNEL);
+}
+
+STATIC uuid_t
+*xfs_uuid_search(uuid_t *new_uuid)
+{
+ unsigned long index = 0;
+ uuid_t *uuid = NULL;
+
+ xa_for_each(&xfs_uuid_table, index, uuid) {
+ if (uuid_equal(uuid, new_uuid))
+ return uuid;
+ }
+ return NULL;
+}
+
+STATIC void
+xfs_uuid_delete(uuid_t *uuid)
+{
+ unsigned long index = 0;
+
+ xa_for_each(&xfs_uuid_table, index, uuid) {
+ xa_erase(&xfs_uuid_table, index);
+ }
+}
void
-xfs_uuid_table_free(void)
+xfs_uuid_table_destroy(void)
{
- if (xfs_uuid_table_size == 0)
- return;
- kfree(xfs_uuid_table);
- xfs_uuid_table = NULL;
- xfs_uuid_table_size = 0;
+ ASSERT(xa_empty(&xfs_uuid_table));
+ xa_destroy(&xfs_uuid_table);
}
/*
@@ -65,7 +95,6 @@ xfs_uuid_mount(
struct xfs_mount *mp)
{
uuid_t *uuid = &mp->m_sb.sb_uuid;
- int hole, i;
/* Publish UUID in struct super_block */
super_set_uuid(mp->m_super, uuid->b, sizeof(*uuid));
@@ -78,29 +107,9 @@ xfs_uuid_mount(
return -EINVAL;
}
- mutex_lock(&xfs_uuid_table_mutex);
- for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) {
- if (uuid_is_null(&xfs_uuid_table[i])) {
- hole = i;
- continue;
- }
- if (uuid_equal(uuid, &xfs_uuid_table[i]))
- goto out_duplicate;
- }
+ if (!xfs_uuid_search(uuid))
+ return xfs_uuid_insert(uuid);
- if (hole < 0) {
- xfs_uuid_table = krealloc(xfs_uuid_table,
- (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table),
- GFP_KERNEL | __GFP_NOFAIL);
- hole = xfs_uuid_table_size++;
- }
- xfs_uuid_table[hole] = *uuid;
- mutex_unlock(&xfs_uuid_table_mutex);
-
- return 0;
-
- out_duplicate:
- mutex_unlock(&xfs_uuid_table_mutex);
xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount", uuid);
return -EINVAL;
}
@@ -110,22 +119,12 @@ xfs_uuid_unmount(
struct xfs_mount *mp)
{
uuid_t *uuid = &mp->m_sb.sb_uuid;
- int i;
if (xfs_has_nouuid(mp))
return;
+ xfs_uuid_delete(uuid);
+ return;
- mutex_lock(&xfs_uuid_table_mutex);
- for (i = 0; i < xfs_uuid_table_size; i++) {
- if (uuid_is_null(&xfs_uuid_table[i]))
- continue;
- if (!uuid_equal(uuid, &xfs_uuid_table[i]))
- continue;
- memset(&xfs_uuid_table[i], 0, sizeof(uuid_t));
- break;
- }
- ASSERT(i < xfs_uuid_table_size);
- mutex_unlock(&xfs_uuid_table_mutex);
}
/*
diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
index b871dfde372b..c3a5035c1fb6 100644
--- a/fs/xfs/xfs_mount.h
+++ b/fs/xfs/xfs_mount.h
@@ -689,7 +689,8 @@ xfs_daddr_to_agbno(struct xfs_mount *mp, xfs_daddr_t d)
return (xfs_agblock_t) do_div(ld, mp->m_sb.sb_agblocks);
}
-extern void xfs_uuid_table_free(void);
+extern void xfs_uuid_table_destroy(void);
+
uint64_t xfs_default_resblks(struct xfs_mount *mp,
enum xfs_free_counter ctr);
extern int xfs_mountfs(xfs_mount_t *mp);
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index bc71aa9dcee8..fc9d2e5acf96 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -2723,7 +2723,7 @@ exit_xfs_fs(void)
xfs_mru_cache_uninit();
xfs_destroy_workqueues();
xfs_destroy_caches();
- xfs_uuid_table_free();
+ xfs_uuid_table_destroy();
}
module_init(init_xfs_fs);
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-01-30 15:42 ` [PATCH] " Lukas Herbolt
@ 2026-01-30 16:55 ` Darrick J. Wong
2026-02-02 7:31 ` Christoph Hellwig
2026-02-02 7:37 ` Christoph Hellwig
1 sibling, 1 reply; 10+ messages in thread
From: Darrick J. Wong @ 2026-01-30 16:55 UTC (permalink / raw)
To: Lukas Herbolt; +Cc: linux-xfs, cem
On Fri, Jan 30, 2026 at 04:42:08PM +0100, Lukas Herbolt wrote:
> Removing the plain array to track the UUIDs and switch
> xarray to make more readable.
>
> Signed-off-by: Lukas Herbolt <lukas@herbolt.com>
> ---
> fs/xfs/xfs_mount.c | 87 +++++++++++++++++++++++-----------------------
> fs/xfs/xfs_mount.h | 3 +-
> fs/xfs/xfs_super.c | 2 +-
> 3 files changed, 46 insertions(+), 46 deletions(-)
>
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index 0953f6ae94ab..35c0d411e0cb 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -42,18 +42,48 @@
> #include "scrub/stats.h"
> #include "xfs_zone_alloc.h"
>
> -static DEFINE_MUTEX(xfs_uuid_table_mutex);
> -static int xfs_uuid_table_size;
> -static uuid_t *xfs_uuid_table;
> +static DEFINE_XARRAY_ALLOC(xfs_uuid_table);
> +
> +/*
> + * Helper fucntions to store UUID in xarray.
> + */
> +STATIC int
> +xfs_uuid_insert(uuid_t *uuid)
> +{
> + uint32_t index = 0;
> +
> + return xa_alloc(&xfs_uuid_table, &index, uuid,
> + xa_limit_32b, GFP_KERNEL);
> +}
> +
> +STATIC uuid_t
> +*xfs_uuid_search(uuid_t *new_uuid)
> +{
> + unsigned long index = 0;
> + uuid_t *uuid = NULL;
> +
> + xa_for_each(&xfs_uuid_table, index, uuid) {
> + if (uuid_equal(uuid, new_uuid))
> + return uuid;
> + }
> + return NULL;
> +}
> +
> +STATIC void
> +xfs_uuid_delete(uuid_t *uuid)
> +{
> + unsigned long index = 0;
> +
> + xa_for_each(&xfs_uuid_table, index, uuid) {
> + xa_erase(&xfs_uuid_table, index);
> + }
Why not store the xarray index in the xfs_mount so you can delete the
entry directly without having to walk the entire array?
And while I'm on about it ... if you're going to change data structures,
why not use rhashtable or something that can do a direct lookup?
> +}
>
> void
> -xfs_uuid_table_free(void)
> +xfs_uuid_table_destroy(void)
> {
> - if (xfs_uuid_table_size == 0)
> - return;
> - kfree(xfs_uuid_table);
> - xfs_uuid_table = NULL;
> - xfs_uuid_table_size = 0;
> + ASSERT(xa_empty(&xfs_uuid_table));
> + xa_destroy(&xfs_uuid_table);
> }
>
> /*
> @@ -65,7 +95,6 @@ xfs_uuid_mount(
> struct xfs_mount *mp)
> {
> uuid_t *uuid = &mp->m_sb.sb_uuid;
> - int hole, i;
>
> /* Publish UUID in struct super_block */
> super_set_uuid(mp->m_super, uuid->b, sizeof(*uuid));
> @@ -78,29 +107,9 @@ xfs_uuid_mount(
> return -EINVAL;
> }
>
> - mutex_lock(&xfs_uuid_table_mutex);
> - for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) {
> - if (uuid_is_null(&xfs_uuid_table[i])) {
> - hole = i;
> - continue;
> - }
> - if (uuid_equal(uuid, &xfs_uuid_table[i]))
> - goto out_duplicate;
> - }
> + if (!xfs_uuid_search(uuid))
> + return xfs_uuid_insert(uuid);
xfs_uuid_table_mutex went away, so what's protecting the lookup and
insert from racing to insert the same uuid twice?
--D
>
> - if (hole < 0) {
> - xfs_uuid_table = krealloc(xfs_uuid_table,
> - (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table),
> - GFP_KERNEL | __GFP_NOFAIL);
> - hole = xfs_uuid_table_size++;
> - }
> - xfs_uuid_table[hole] = *uuid;
> - mutex_unlock(&xfs_uuid_table_mutex);
> -
> - return 0;
> -
> - out_duplicate:
> - mutex_unlock(&xfs_uuid_table_mutex);
> xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount", uuid);
> return -EINVAL;
> }
> @@ -110,22 +119,12 @@ xfs_uuid_unmount(
> struct xfs_mount *mp)
> {
> uuid_t *uuid = &mp->m_sb.sb_uuid;
> - int i;
>
> if (xfs_has_nouuid(mp))
> return;
> + xfs_uuid_delete(uuid);
> + return;
>
> - mutex_lock(&xfs_uuid_table_mutex);
> - for (i = 0; i < xfs_uuid_table_size; i++) {
> - if (uuid_is_null(&xfs_uuid_table[i]))
> - continue;
> - if (!uuid_equal(uuid, &xfs_uuid_table[i]))
> - continue;
> - memset(&xfs_uuid_table[i], 0, sizeof(uuid_t));
> - break;
> - }
> - ASSERT(i < xfs_uuid_table_size);
> - mutex_unlock(&xfs_uuid_table_mutex);
> }
>
> /*
> diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> index b871dfde372b..c3a5035c1fb6 100644
> --- a/fs/xfs/xfs_mount.h
> +++ b/fs/xfs/xfs_mount.h
> @@ -689,7 +689,8 @@ xfs_daddr_to_agbno(struct xfs_mount *mp, xfs_daddr_t d)
> return (xfs_agblock_t) do_div(ld, mp->m_sb.sb_agblocks);
> }
>
> -extern void xfs_uuid_table_free(void);
> +extern void xfs_uuid_table_destroy(void);
> +
> uint64_t xfs_default_resblks(struct xfs_mount *mp,
> enum xfs_free_counter ctr);
> extern int xfs_mountfs(xfs_mount_t *mp);
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index bc71aa9dcee8..fc9d2e5acf96 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -2723,7 +2723,7 @@ exit_xfs_fs(void)
> xfs_mru_cache_uninit();
> xfs_destroy_workqueues();
> xfs_destroy_caches();
> - xfs_uuid_table_free();
> + xfs_uuid_table_destroy();
> }
>
> module_init(init_xfs_fs);
>
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> --
> 2.52.0
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-01-30 16:55 ` Darrick J. Wong
@ 2026-02-02 7:31 ` Christoph Hellwig
2026-02-02 9:37 ` Lukas Herbolt
0 siblings, 1 reply; 10+ messages in thread
From: Christoph Hellwig @ 2026-02-02 7:31 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Lukas Herbolt, linux-xfs, cem
On Fri, Jan 30, 2026 at 08:55:34AM -0800, Darrick J. Wong wrote:
> > + xa_erase(&xfs_uuid_table, index);
> > + }
>
> Why not store the xarray index in the xfs_mount so you can delete the
> entry directly without having to walk the entire array?
Yeah, that makes a lot of sense.
> And while I'm on about it ... if you're going to change data structures,
> why not use rhashtable or something that can do a direct lookup?
rhashtables require quite a bit of boilerplate. Probably not worth
if for a single lookup in a relatively small colletion once per
mount. But yeah, if only we had a data structure that allows
directly lookups without all that boilerplate..
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-01-30 15:42 ` [PATCH] " Lukas Herbolt
2026-01-30 16:55 ` Darrick J. Wong
@ 2026-02-02 7:37 ` Christoph Hellwig
2026-02-02 9:38 ` Lukas Herbolt
1 sibling, 1 reply; 10+ messages in thread
From: Christoph Hellwig @ 2026-02-02 7:37 UTC (permalink / raw)
To: Lukas Herbolt; +Cc: linux-xfs, cem
> +STATIC int
We're phasing out the magic STATIC, so pleae just use plain static
here.
> +xfs_uuid_insert(uuid_t *uuid)
The somewhat unique XFS coding style uses separate lines for each
argument:
static int
xfs_uuid_insert(
uuid_t *uuid)
> +{
> + uint32_t index = 0;
.. and aligns the variables the same way:
{
uint32_t index = 0;
Although this one will go away with Darrick's suggestion anyway.
> +
> + return xa_alloc(&xfs_uuid_table, &index, uuid,
> + xa_limit_32b, GFP_KERNEL);
> +}
> +
> +STATIC uuid_t
> +*xfs_uuid_search(uuid_t *new_uuid)
The * for pointers goes with the type:
static uuid_t *
xfs_uuid_search(
uuid_t *new_uuid)
> + uuid_t *uuid = NULL;
no need to initialize the iterator to NULL before xa_for_each.
> +STATIC void
> +xfs_uuid_delete(uuid_t *uuid)
> +{
> + unsigned long index = 0;
> +
> + xa_for_each(&xfs_uuid_table, index, uuid) {
> + xa_erase(&xfs_uuid_table, index);
> + }
I don't think this works as expected, as it just erases all uuids in the
table.
> +}
>
> void
> -xfs_uuid_table_free(void)
> +xfs_uuid_table_destroy(void)
I'd drop this rename. Free works just fine here as a name.
> + if (!xfs_uuid_search(uuid))
> + return xfs_uuid_insert(uuid);
>
> xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount", uuid);
> return -EINVAL;
Just return an error here if xfs_uuid_search finds something, and then
open code the insert in the straight line path.
> @@ -110,22 +119,12 @@ xfs_uuid_unmount(
> struct xfs_mount *mp)
> {
> uuid_t *uuid = &mp->m_sb.sb_uuid;
>
> if (xfs_has_nouuid(mp))
> return;
> + xfs_uuid_delete(uuid);
> + return;
No need for the last return. Also I think you can just open code
xfs_uuid_delete here.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-02-02 7:31 ` Christoph Hellwig
@ 2026-02-02 9:37 ` Lukas Herbolt
2026-02-02 18:50 ` Darrick J. Wong
0 siblings, 1 reply; 10+ messages in thread
From: Lukas Herbolt @ 2026-02-02 9:37 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Darrick J. Wong, linux-xfs, cem
On 2026-02-02 08:31, Christoph Hellwig wrote:
> On Fri, Jan 30, 2026 at 08:55:34AM -0800, Darrick J. Wong wrote:
>> > + xa_erase(&xfs_uuid_table, index);
>> > + }
>>
>> Why not store the xarray index in the xfs_mount so you can delete the
>> entry directly without having to walk the entire array?
>
> Yeah, that makes a lot of sense.
>
I did not want to touch the xfs_mount but if there is no objection
against,
I will add the index there.
>> And while I'm on about it ... if you're going to change data
>> structures,
>> why not use rhashtable or something that can do a direct lookup?
>
> rhashtables require quite a bit of boilerplate. Probably not worth
> if for a single lookup in a relatively small colletion once per
> mount. But yeah, if only we had a data structure that allows
> directly lookups without all that boilerplate..
I do not have strong preference here.
--
-lhe
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-02-02 7:37 ` Christoph Hellwig
@ 2026-02-02 9:38 ` Lukas Herbolt
0 siblings, 0 replies; 10+ messages in thread
From: Lukas Herbolt @ 2026-02-02 9:38 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-xfs, cem
On 2026-02-02 08:37, Christoph Hellwig wrote:
>> +STATIC int
>
> We're phasing out the magic STATIC, so pleae just use plain static
> here.
>
>> +xfs_uuid_insert(uuid_t *uuid)
>
> The somewhat unique XFS coding style uses separate lines for each
> argument:
>
> static int
> xfs_uuid_insert(
> uuid_t *uuid)
>
>> +{
>> + uint32_t index = 0;
>
> .. and aligns the variables the same way:
>
> {
> uint32_t index = 0;
>
> Although this one will go away with Darrick's suggestion anyway.
>
>> +
>> + return xa_alloc(&xfs_uuid_table, &index, uuid,
>> + xa_limit_32b, GFP_KERNEL);
>> +}
>> +
>> +STATIC uuid_t
>> +*xfs_uuid_search(uuid_t *new_uuid)
>
> The * for pointers goes with the type:
>
> static uuid_t *
> xfs_uuid_search(
> uuid_t *new_uuid)
>
>> + uuid_t *uuid = NULL;
>
> no need to initialize the iterator to NULL before xa_for_each.
>
>> +STATIC void
>> +xfs_uuid_delete(uuid_t *uuid)
>> +{
>> + unsigned long index = 0;
>> +
>> + xa_for_each(&xfs_uuid_table, index, uuid) {
>> + xa_erase(&xfs_uuid_table, index);
>> + }
>
> I don't think this works as expected, as it just erases all uuids in
> the
> table.
>
>> +}
>>
>> void
>> -xfs_uuid_table_free(void)
>> +xfs_uuid_table_destroy(void)
>
> I'd drop this rename. Free works just fine here as a name.
>
>> + if (!xfs_uuid_search(uuid))
>> + return xfs_uuid_insert(uuid);
>>
>> xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount",
>> uuid);
>> return -EINVAL;
>
> Just return an error here if xfs_uuid_search finds something, and then
> open code the insert in the straight line path.
>
>> @@ -110,22 +119,12 @@ xfs_uuid_unmount(
>> struct xfs_mount *mp)
>> {
>> uuid_t *uuid = &mp->m_sb.sb_uuid;
>>
>> if (xfs_has_nouuid(mp))
>> return;
>> + xfs_uuid_delete(uuid);
>> + return;
>
> No need for the last return. Also I think you can just open code
> xfs_uuid_delete here.
Thank you for all the comments! I will do all the changes.
--
-lhe
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-02-02 9:37 ` Lukas Herbolt
@ 2026-02-02 18:50 ` Darrick J. Wong
2026-02-03 5:17 ` Christoph Hellwig
0 siblings, 1 reply; 10+ messages in thread
From: Darrick J. Wong @ 2026-02-02 18:50 UTC (permalink / raw)
To: Lukas Herbolt; +Cc: Christoph Hellwig, linux-xfs, cem
On Mon, Feb 02, 2026 at 10:37:23AM +0100, Lukas Herbolt wrote:
> On 2026-02-02 08:31, Christoph Hellwig wrote:
> > On Fri, Jan 30, 2026 at 08:55:34AM -0800, Darrick J. Wong wrote:
> > > > + xa_erase(&xfs_uuid_table, index);
> > > > + }
> > >
> > > Why not store the xarray index in the xfs_mount so you can delete the
> > > entry directly without having to walk the entire array?
> >
> > Yeah, that makes a lot of sense.
> >
> I did not want to touch the xfs_mount but if there is no objection against,
> I will add the index there.
>
> > > And while I'm on about it ... if you're going to change data
> > > structures,
> > > why not use rhashtable or something that can do a direct lookup?
> >
> > rhashtables require quite a bit of boilerplate. Probably not worth
> > if for a single lookup in a relatively small colletion once per
> > mount. But yeah, if only we had a data structure that allows
> > directly lookups without all that boilerplate..
>
> I do not have strong preference here.
<shrug> Since the original message said "krealloc prints out warning if
allocation is bigger than 2x PAGE_SIZE", I figured that meant you were
trying to mount more than (2 * 4096) / 16 == 512 different xfs
filesystems on the same host.
I don't have a particular problem with the array search and large memory
allocation since I never mount that many filesystems, but you would
appear to be the first user to complain about a scaling limit there...
:)
--D
> --
> -lhe
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-02-02 18:50 ` Darrick J. Wong
@ 2026-02-03 5:17 ` Christoph Hellwig
2026-02-03 7:23 ` Darrick J. Wong
0 siblings, 1 reply; 10+ messages in thread
From: Christoph Hellwig @ 2026-02-03 5:17 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Lukas Herbolt, Christoph Hellwig, linux-xfs, cem
On Mon, Feb 02, 2026 at 10:50:13AM -0800, Darrick J. Wong wrote:
> > I do not have strong preference here.
>
> <shrug> Since the original message said "krealloc prints out warning if
> allocation is bigger than 2x PAGE_SIZE", I figured that meant you were
> trying to mount more than (2 * 4096) / 16 == 512 different xfs
> filesystems on the same host.
I don't remember any such message. But array or xarray iterations
should still scale well enough for a single mount time operation into
the 10.000nds of entries.
> I don't have a particular problem with the array search and large memory
> allocation since I never mount that many filesystems, but you would
> appear to be the first user to complain about a scaling limit there...
I was really just concerned about a single large allocation. But yeah,
it's not that large... That beind said I think the xarray version will
also look nicer than the original one.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array.
2026-02-03 5:17 ` Christoph Hellwig
@ 2026-02-03 7:23 ` Darrick J. Wong
0 siblings, 0 replies; 10+ messages in thread
From: Darrick J. Wong @ 2026-02-03 7:23 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Lukas Herbolt, linux-xfs, cem
On Mon, Feb 02, 2026 at 09:17:31PM -0800, Christoph Hellwig wrote:
> On Mon, Feb 02, 2026 at 10:50:13AM -0800, Darrick J. Wong wrote:
> > > I do not have strong preference here.
> >
> > <shrug> Since the original message said "krealloc prints out warning if
> > allocation is bigger than 2x PAGE_SIZE", I figured that meant you were
> > trying to mount more than (2 * 4096) / 16 == 512 different xfs
> > filesystems on the same host.
>
> I don't remember any such message. But array or xarray iterations
> should still scale well enough for a single mount time operation into
> the 10.000nds of entries.
>
> > I don't have a particular problem with the array search and large memory
> > allocation since I never mount that many filesystems, but you would
> > appear to be the first user to complain about a scaling limit there...
>
> I was really just concerned about a single large allocation. But yeah,
> it's not that large... That beind said I think the xarray version will
> also look nicer than the original one.
It's better than the raw kvalloc'd blob we have now :)
--D
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-02-03 7:23 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-30 15:42 [PATCH 0/1] xfs: Use xarray to track SB UUIDs instead of plain array Lukas Herbolt
2026-01-30 15:42 ` [PATCH] " Lukas Herbolt
2026-01-30 16:55 ` Darrick J. Wong
2026-02-02 7:31 ` Christoph Hellwig
2026-02-02 9:37 ` Lukas Herbolt
2026-02-02 18:50 ` Darrick J. Wong
2026-02-03 5:17 ` Christoph Hellwig
2026-02-03 7:23 ` Darrick J. Wong
2026-02-02 7:37 ` Christoph Hellwig
2026-02-02 9:38 ` Lukas Herbolt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox