subject:"FreeBSD 14.0\-BETA2 Now Available"

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available) [block_cloning and zilsaxattr missing from loader's features_for_read]

2023-09-18 Thread Mark Millard

On Sep 18, 2023, at 17:05, Alexander Motin  wrote:

> On 18.09.2023 19:21, Mark Millard wrote:
>> On Sep 18, 2023, at 15:51, Mark Millard  wrote:
>>> Alexander Motin  wrote on
>>> Date: Mon, 18 Sep 2023 13:26:56 UTC :
 block_cloning feature is marked as READONLY_COMPAT. It should not
 require any special handling from the boot code.
>>> 
>>> From stand/libsa/zfs/zfsimpl.c but adding a comment about the
>>> read-only compatibility status of each entry:
>>> 
>>> /*
>>> * List of ZFS features supported for read
>>> */
>> static const char *features_for_read[] = {
>>>"com.datto:bookmark_v2", // READ-ONLY COMPATIBLE no
>>>"com.datto:encryption", // READ-ONLY COMPATIBLE no
>>>"com.datto:resilver_defer", // READ-ONLY COMPATIBLE yes
>>>"com.delphix:bookmark_written", // READ-ONLY COMPATIBLE no
>>>"com.delphix:device_removal", // READ-ONLY COMPATIBLE no
>>>"com.delphix:embedded_data", // READ-ONLY COMPATIBLE no
>>>"com.delphix:extensible_dataset", // READ-ONLY COMPATIBLE no
>>>"com.delphix:head_errlog", // READ-ONLY COMPATIBLE no
>>>"com.delphix:hole_birth", // READ-ONLY COMPATIBLE no
>>>"com.delphix:obsolete_counts", // READ-ONLY COMPATIBLE yes
>>>"com.delphix:spacemap_histogram", // READ-ONLY COMPATIBLE yes
>>>"com.delphix:spacemap_v2", // READ-ONLY COMPATIBLE yes
>>>"com.delphix:zpool_checkpoint", // READ-ONLY COMPATIBLE yes
>>>"com.intel:allocation_classes", // READ-ONLY COMPATIBLE yes
>>>"com.joyent:multi_vdev_crash_dump", // READ-ONLY COMPATIBLE no
>>>"com.klarasystems:vdev_zaps_v2", // READ-ONLY COMPATIBLE no
>>>"org.freebsd:zstd_compress", // READ-ONLY COMPATIBLE no
>>>"org.illumos:lz4_compress", // READ-ONLY COMPATIBLE no
>>>"org.illumos:sha512", // READ-ONLY COMPATIBLE no
>>>"org.illumos:skein", // READ-ONLY COMPATIBLE no
>>>"org.open-zfs:large_blocks", // READ-ONLY COMPATIBLE no
>>>"org.openzfs:blake3", // READ-ONLY COMPATIBLE no
>>>"org.zfsonlinux:allocation_classes", // READ-ONLY COMPATIBLE yes
>>>"org.zfsonlinux:large_dnode", // READ-ONLY COMPATIBLE no
>>>NULL
>>> };
>>> 
>>> So it appears that the design is that both "no" and "yes" ones
>>> that are known to be supported are listed and anything else is
>>> supposed to lead to rejection until explicitly added as
>>> known-compatibile.
> 
> I don't think so.  I think somebody by mistake added first featured that 
> should not be here, and then others continued this irrelevant routine. My own 
> development server/builder is happily running latest main with ZFS root 
> without any patches and with block cloning not only enabled, but even active. 
>  So as I have told, it is not needed:
> 
> mav@srv:/root# zpool get all | grep clon
> mavlab  bcloneused 20.5M  -
> mavlab  bclonesaved20.9M  -
> mavlab  bcloneratio2.02x  -
> mavlab  feature@block_cloning  active local
> 
> Somebody should go through the list and clean in up from read-compatible 
> features and document it, unless there are some features that were 
> re-qualified at some point, I haven't checked if it could be.
> 
>>> This matches up with stand/libsa/zfs/zfsimpl.c 's:
>>> 
>>> static int
>>> nvlist_check_features_for_read(nvlist_t *nvl)
>>> {
> ...
>>>rc = nvlist_find(nvl, ZPOOL_CONFIG_FEATURES_FOR_READ,
>>>DATA_TYPE_NVLIST, NULL, , NULL);
> 
> Take a note it reads ZPOOL_CONFIG_FEATURES_FOR_READ.  Same time features 
> declared as READONLY_COMPAT are stored in FEATURES_FOR_WRITE, that boot 
> loader does not even care.
> 
>>> I do not know if vfs.zfs.bclone_enabled=0 leads the loader
>>> to see vs. not-see a "com.fudosecurity:block_cloning".
> 
> bclone_enabled=0 block copy_file_range() usage, that should keep the feature 
> enabled, but not active.  It could be related if the feature would be in 
> FEATURES_FOR_WRITE, but here and now it is not.
> 
>> It appears that 2 additions afeter opebzfas-2.1-freebsd are
>> missing from the above list:
>> com.fudosecurity:block_cloning
>> org.openzfs:zilsaxattr
> 
> Nothing of ZIL is required for read-only import.  So no, it is also not 
> needed.

Thanks for the details in your notes, including that bclone_enabled=0
is not relevant.

As a result I found out about zhack feature stat POOLNAME that shows
the ZPOOL_CONFIG_FEATURES_FOR_READ separately from then ones for
write.

Looking at the pool that I used for testing block_cloning
via poudriere bulk build activity (and sorting the for_*_obj
lists produced) . . .

The for_read_obj list (with matching line added as a suffix):

com.datto:bookmark_v2 = 0   "com.datto:bookmark_v2", // 
READ-ONLY COMPATIBLE no
com.datto:encryption = 0"com.datto:encryption", // 
READ-ONLY

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available) [block_cloning and zilsaxattr missing from loader's features_for_read]

2023-09-18 Thread Alexander Motin


On 18.09.2023 19:21, Mark Millard wrote:

On Sep 18, 2023, at 15:51, Mark Millard  wrote:

Alexander Motin  wrote on
Date: Mon, 18 Sep 2023 13:26:56 UTC :

block_cloning feature is marked as READONLY_COMPAT. It should not
require any special handling from the boot code.


 From stand/libsa/zfs/zfsimpl.c but adding a comment about the
read-only compatibility status of each entry:

/*
* List of ZFS features supported for read
*/

static const char *features_for_read[] = {

"com.datto:bookmark_v2", // READ-ONLY COMPATIBLE no
"com.datto:encryption", // READ-ONLY COMPATIBLE no
"com.datto:resilver_defer", // READ-ONLY COMPATIBLE yes
"com.delphix:bookmark_written", // READ-ONLY COMPATIBLE no
"com.delphix:device_removal", // READ-ONLY COMPATIBLE no
"com.delphix:embedded_data", // READ-ONLY COMPATIBLE no
"com.delphix:extensible_dataset", // READ-ONLY COMPATIBLE no
"com.delphix:head_errlog", // READ-ONLY COMPATIBLE no
"com.delphix:hole_birth", // READ-ONLY COMPATIBLE no
"com.delphix:obsolete_counts", // READ-ONLY COMPATIBLE yes
"com.delphix:spacemap_histogram", // READ-ONLY COMPATIBLE yes
"com.delphix:spacemap_v2", // READ-ONLY COMPATIBLE yes
"com.delphix:zpool_checkpoint", // READ-ONLY COMPATIBLE yes
"com.intel:allocation_classes", // READ-ONLY COMPATIBLE yes
"com.joyent:multi_vdev_crash_dump", // READ-ONLY COMPATIBLE no
"com.klarasystems:vdev_zaps_v2", // READ-ONLY COMPATIBLE no
"org.freebsd:zstd_compress", // READ-ONLY COMPATIBLE no
"org.illumos:lz4_compress", // READ-ONLY COMPATIBLE no
"org.illumos:sha512", // READ-ONLY COMPATIBLE no
"org.illumos:skein", // READ-ONLY COMPATIBLE no
"org.open-zfs:large_blocks", // READ-ONLY COMPATIBLE no
"org.openzfs:blake3", // READ-ONLY COMPATIBLE no
"org.zfsonlinux:allocation_classes", // READ-ONLY COMPATIBLE yes
"org.zfsonlinux:large_dnode", // READ-ONLY COMPATIBLE no
NULL
};

So it appears that the design is that both "no" and "yes" ones
that are known to be supported are listed and anything else is
supposed to lead to rejection until explicitly added as
known-compatibile.


I don't think so.  I think somebody by mistake added first featured that 
should not be here, and then others continued this irrelevant routine. 
My own development server/builder is happily running latest main with 
ZFS root without any patches and with block cloning not only enabled, 
but even active.  So as I have told, it is not needed:


mav@srv:/root# zpool get all | grep clon
mavlab  bcloneused 20.5M  -
mavlab  bclonesaved20.9M  -
mavlab  bcloneratio2.02x  -
mavlab  feature@block_cloning  active local

Somebody should go through the list and clean in up from read-compatible 
features and document it, unless there are some features that were 
re-qualified at some point, I haven't checked if it could be.



This matches up with stand/libsa/zfs/zfsimpl.c 's:

static int
nvlist_check_features_for_read(nvlist_t *nvl)
{

...

rc = nvlist_find(nvl, ZPOOL_CONFIG_FEATURES_FOR_READ,
DATA_TYPE_NVLIST, NULL, , NULL);


Take a note it reads ZPOOL_CONFIG_FEATURES_FOR_READ.  Same time features 
declared as READONLY_COMPAT are stored in FEATURES_FOR_WRITE, that boot 
loader does not even care.



I do not know if vfs.zfs.bclone_enabled=0 leads the loader
to see vs. not-see a "com.fudosecurity:block_cloning".


bclone_enabled=0 block copy_file_range() usage, that should keep the 
feature enabled, but not active.  It could be related if the feature 
would be in FEATURES_FOR_WRITE, but here and now it is not.



It appears that 2 additions afeter opebzfas-2.1-freebsd are
missing from the above list:

com.fudosecurity:block_cloning
org.openzfs:zilsaxattr


Nothing of ZIL is required for read-only import.  So no, it is also not 
needed.


--
Alexander Motin

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available) [block_cloning and zilsaxattr missing from loader's features_for_read]

2023-09-18 Thread Mark Millard




On Sep 18, 2023, at 15:51, Mark Millard  wrote:

> Alexander Motin  wrote on
> Date: Mon, 18 Sep 2023 13:26:56 UTC :
> 
>> block_cloning feature is marked as READONLY_COMPAT. It should not 
>> require any special handling from the boot code.
> 
> From stand/libsa/zfs/zfsimpl.c but adding a comment about the
> read-only compatibility status of each entry:
> 
> /*
> * List of ZFS features supported for read
> */
> static const char *features_e: vfs.zfs.bclone_enabled

Sorry, a stupid error of mine messed up the above line.
It should have been:

static const char *features_for_read[] = {

>"com.datto:bookmark_v2", // READ-ONLY COMPATIBLE no
>"com.datto:encryption", // READ-ONLY COMPATIBLE no
>"com.datto:resilver_defer", // READ-ONLY COMPATIBLE yes
>"com.delphix:bookmark_written", // READ-ONLY COMPATIBLE no
>"com.delphix:device_removal", // READ-ONLY COMPATIBLE no
>"com.delphix:embedded_data", // READ-ONLY COMPATIBLE no
>"com.delphix:extensible_dataset", // READ-ONLY COMPATIBLE no
>"com.delphix:head_errlog", // READ-ONLY COMPATIBLE no
>"com.delphix:hole_birth", // READ-ONLY COMPATIBLE no
>"com.delphix:obsolete_counts", // READ-ONLY COMPATIBLE yes
>"com.delphix:spacemap_histogram", // READ-ONLY COMPATIBLE yes
>"com.delphix:spacemap_v2", // READ-ONLY COMPATIBLE yes
>"com.delphix:zpool_checkpoint", // READ-ONLY COMPATIBLE yes
>"com.intel:allocation_classes", // READ-ONLY COMPATIBLE yes
>"com.joyent:multi_vdev_crash_dump", // READ-ONLY COMPATIBLE no
>"com.klarasystems:vdev_zaps_v2", // READ-ONLY COMPATIBLE no
>"org.freebsd:zstd_compress", // READ-ONLY COMPATIBLE no
>"org.illumos:lz4_compress", // READ-ONLY COMPATIBLE no
>"org.illumos:sha512", // READ-ONLY COMPATIBLE no
>"org.illumos:skein", // READ-ONLY COMPATIBLE no
>"org.open-zfs:large_blocks", // READ-ONLY COMPATIBLE no
>"org.openzfs:blake3", // READ-ONLY COMPATIBLE no
>"org.zfsonlinux:allocation_classes", // READ-ONLY COMPATIBLE yes
>"org.zfsonlinux:large_dnode", // READ-ONLY COMPATIBLE no
>NULL
> };
> 
> So it appears that the design is that both "no" and "yes" ones
> that are known to be supported are listed and anything else is
> supposed to lead to rejection until explicitly added as
> known-compatibile.
> 
> This matches up with stand/libsa/zfs/zfsimpl.c 's:
> 
> static int
> nvlist_check_features_for_read(nvlist_t *nvl)
> {
>nvlist_t *features = NULL;
>nvs_data_t *data;
>nvp_header_t *nvp;
>nv_string_t *nvp_name;
>int rc;
> 
>rc = nvlist_find(nvl, ZPOOL_CONFIG_FEATURES_FOR_READ,
>DATA_TYPE_NVLIST, NULL, , NULL);
>switch (rc) {
>case 0:
>break;  /* Continue with checks */
> 
>case ENOENT:
>return (0); /* All features are disabled */
> 
>default:
>return (rc);/* Error while reading nvlist */
>}
> 
>data = (nvs_data_t *)features->nv_data;
>nvp = >nvl_pair;  /* first pair in nvlist */
> 
>while (nvp->encoded_size != 0 && nvp->decoded_size != 0) {
>int i, found;
> 
>nvp_name = (nv_string_t *)((uintptr_t)nvp + sizeof(*nvp));
>found = 0;
> 
>for (i = 0; features_for_read[i] != NULL; i++) {
>if (memcmp(nvp_name->nv_data, features_for_read[i],
>nvp_name->nv_size) == 0) {
>found = 1;
>break;
>}
>}
> 
>if (!found) {
>printf("ZFS: unsupported feature: %.*s\n",
>nvp_name->nv_size, nvp_name->nv_data);
>rc = EIO;
>}
>nvp = (nvp_header_t *)((uint8_t *)nvp + nvp->encoded_size);
>}
>nvlist_destroy(features);
> 
>return (rc);
> }
> 
> I do not know if vfs.zfs.bclone_enabled=0 leads the loader
> to see vs. not-see a "com.fudosecurity:block_cloning".

It appears that 2 additions afeter opebzfas-2.1-freebsd are
missing from the above list:

com.fudosecurity:block_cloning
org.openzfs:zilsaxattr

See, for reference (but shorter naming):

# diff -u99 
/usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd 
/usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2
--- 
/usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd 
2021-06-24 20:08:57.206621000 -0700
+++ /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2 
2023-06-10 15:51:13.220607000 -0700
@@ -1,34 +1,40 @@
-# Features supported by OpenZFS 2.1 on FreeBSD
+# Features supported by OpenZFS 2.2 on Linux and FreeBSD
 allocation_classes
 async_destroy
+blake3
+block_cloning
 bookmark_v2

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-18 Thread Mark Millard

Alexander Motin  wrote on
Date: Mon, 18 Sep 2023 13:26:56 UTC :

> block_cloning feature is marked as READONLY_COMPAT. It should not 
> require any special handling from the boot code.

From stand/libsa/zfs/zfsimpl.c but adding a comment about the
read-only compatibility status of each entry:

/*
 * List of ZFS features supported for read
 */
static const char *features_e: vfs.zfs.bclone_enabled
"com.datto:bookmark_v2",// READ-ONLY COMPATIBLE no
"com.datto:encryption", // READ-ONLY COMPATIBLE no
"com.datto:resilver_defer", // READ-ONLY COMPATIBLE yes
"com.delphix:bookmark_written", // READ-ONLY COMPATIBLE no
"com.delphix:device_removal",   // READ-ONLY COMPATIBLE no
"com.delphix:embedded_data",// READ-ONLY COMPATIBLE no
"com.delphix:extensible_dataset",   // READ-ONLY COMPATIBLE no
"com.delphix:head_errlog",  // READ-ONLY COMPATIBLE no
"com.delphix:hole_birth",   // READ-ONLY COMPATIBLE no
"com.delphix:obsolete_counts",  // READ-ONLY COMPATIBLE yes
"com.delphix:spacemap_histogram",   // READ-ONLY COMPATIBLE yes
"com.delphix:spacemap_v2",  // READ-ONLY COMPATIBLE yes
"com.delphix:zpool_checkpoint", // READ-ONLY COMPATIBLE yes
"com.intel:allocation_classes", // READ-ONLY COMPATIBLE yes
"com.joyent:multi_vdev_crash_dump", // READ-ONLY COMPATIBLE no
"com.klarasystems:vdev_zaps_v2",// READ-ONLY COMPATIBLE no
"org.freebsd:zstd_compress",// READ-ONLY COMPATIBLE no
"org.illumos:lz4_compress", // READ-ONLY COMPATIBLE no
"org.illumos:sha512",   // READ-ONLY COMPATIBLE no
"org.illumos:skein",// READ-ONLY COMPATIBLE no
"org.open-zfs:large_blocks",// READ-ONLY COMPATIBLE no
"org.openzfs:blake3",   // READ-ONLY COMPATIBLE no
"org.zfsonlinux:allocation_classes",// READ-ONLY COMPATIBLE yes
"org.zfsonlinux:large_dnode",   // READ-ONLY COMPATIBLE no
NULL
};

So it appears that the design is that both "no" and "yes" ones
that are known to be supported are listed and anything else is
supposed to lead to rejection until explicitly added as
known-compatibile.

This matches up with stand/libsa/zfs/zfsimpl.c 's:

static int
nvlist_check_features_for_read(nvlist_t *nvl)
{
nvlist_t *features = NULL;
nvs_data_t *data;
nvp_header_t *nvp;
nv_string_t *nvp_name;
int rc;

rc = nvlist_find(nvl, ZPOOL_CONFIG_FEATURES_FOR_READ,
DATA_TYPE_NVLIST, NULL, , NULL);
switch (rc) {
case 0:
break;  /* Continue with checks */

case ENOENT:
return (0); /* All features are disabled */

default:
return (rc);/* Error while reading nvlist */
}

data = (nvs_data_t *)features->nv_data;
nvp = >nvl_pair;  /* first pair in nvlist */

while (nvp->encoded_size != 0 && nvp->decoded_size != 0) {
int i, found;

nvp_name = (nv_string_t *)((uintptr_t)nvp + sizeof(*nvp));
found = 0;

for (i = 0; features_for_read[i] != NULL; i++) {
if (memcmp(nvp_name->nv_data, features_for_read[i],
nvp_name->nv_size) == 0) {
found = 1;
break;
}
}

if (!found) {
printf("ZFS: unsupported feature: %.*s\n",
nvp_name->nv_size, nvp_name->nv_data);
rc = EIO;
}
nvp = (nvp_header_t *)((uint8_t *)nvp + nvp->encoded_size);
}
nvlist_destroy(features);

return (rc);
}

I do not know if vfs.zfs.bclone_enabled=0 leads the loader
to see vs. not-see a "com.fudosecurity:block_cloning".

===
Mark Millard
marklmi at yahoo.com

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-18 Thread Tomoaki AOKI

At least, if I read the code correctly,
"com.fudosecurity:block_cloning",
should be added to array
*features_for_read[]
of stand/libsa/zfs/zfsimpl.c.

There are check codes like below, so without it, boot codes would
reject to boot from any pool having block_cloning feature enabled.
Am I missing something?

>   for (i = 0; features_for_read[i] != NULL; i++) {
>   if (memcmp(nvp_name->nv_data,
features_for_read[i], nvp_name->nv_size) == 0) {
>   found = 1;
>   break;
>   }
>   }
> 
>   if (!found) {
>   printf("ZFS: unsupported feature: %.*s\n",
>   nvp_name->nv_size, nvp_name->nv_data);
>   rc = EIO;
>   }

Regards.


On Mon, 18 Sep 2023 09:26:56 -0400
Alexander Motin  wrote:

> block_cloning feature is marked as READONLY_COMPAT.  It should not 
> require any special handling from the boot code.
> 
> On 18.09.2023 07:22, Tomoaki AOKI wrote:
> > Really OK?
> > 
> > I cannot find block_cloning in array *features_for_read[] of
> > stand/libsa/zfs/zfsimpl.c, which possibly mean boot codes (including
> > loader) cannot boot from Root-on-ZFS pool having block_cloning active.
> > 
> > Not sure adding '"com.fudosecurity:block_cloning",' here is sufficient
> > or not. Possibly more works are needed.
> > 
> > IMHO, all default-enabled features should be safe for booting.
> > Implement features with disalded, impement boot codes to support them,
> > then finally enable them by default should be the only valid route.
> > 
> > 
> > [1] https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c
> > 
> > 
> > On Mon, 18 Sep 2023 07:31:46 +0200
> > Martin Matuska  wrote:
> > 
> >> I vote for enabling block cloning on main :-)
> >>
> >> mm
> >>
> >> On 16. 9. 2023 19:14, Alexander Motin wrote:
> >>> On 16.09.2023 01:25, Graham Perrin wrote:
>  On 16/09/2023 01:28, Glen Barber wrote:
> > o A fix for the ZFS block_cloning feature has been implemented.
> 
>  Thanks
> 
>  I see
>  ,
>  with
>  
>  in stable/14.
> 
>  As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT
>  n265350-72d97e1dd9cc): should we assume that additional fixes, not
>  necessarily in time for 14.0-RELEASE, will be required before
>  vfs.zfs.bclone_enabled can default to 1?
> >>>
> >>> I am not aware of any block cloning issues now.  All this thread about
> >>> bclone_enabled actually started after I asked why it is still
> >>> disabled. Thanks to Mark Millard for spotting this issue I could fix,
> >>> but now we are back at the point of re-enabling it again.  Since the
> >>> tunable does not even exist anywhere outside of FreeBSD base tree, I'd
> >>> propose to give this code another try here too.  I see no point to
> >>> have it disabled at least in main unless somebody needs time to run
> >>> some specific tests first.
> > 
> 
> -- 
> Alexander Motin

-- 
Tomoaki AOKI

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-18 Thread Alexander Motin

block_cloning feature is marked as READONLY_COMPAT.  It should not 
require any special handling from the boot code.


On 18.09.2023 07:22, Tomoaki AOKI wrote:

Really OK?

I cannot find block_cloning in array *features_for_read[] of
stand/libsa/zfs/zfsimpl.c, which possibly mean boot codes (including
loader) cannot boot from Root-on-ZFS pool having block_cloning active.

Not sure adding '"com.fudosecurity:block_cloning",' here is sufficient
or not. Possibly more works are needed.

IMHO, all default-enabled features should be safe for booting.
Implement features with disalded, impement boot codes to support them,
then finally enable them by default should be the only valid route.


[1] https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c


On Mon, 18 Sep 2023 07:31:46 +0200
Martin Matuska  wrote:


I vote for enabling block cloning on main :-)

mm

On 16. 9. 2023 19:14, Alexander Motin wrote:

On 16.09.2023 01:25, Graham Perrin wrote:

On 16/09/2023 01:28, Glen Barber wrote:

o A fix for the ZFS block_cloning feature has been implemented.


Thanks

I see
,
with

in stable/14.

As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT
n265350-72d97e1dd9cc): should we assume that additional fixes, not
necessarily in time for 14.0-RELEASE, will be required before
vfs.zfs.bclone_enabled can default to 1?


I am not aware of any block cloning issues now.  All this thread about
bclone_enabled actually started after I asked why it is still
disabled. Thanks to Mark Millard for spotting this issue I could fix,
but now we are back at the point of re-enabling it again.  Since the
tunable does not even exist anywhere outside of FreeBSD base tree, I'd
propose to give this code another try here too.  I see no point to
have it disabled at least in main unless somebody needs time to run
some specific tests first.




--
Alexander Motin

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-18 Thread Tomoaki AOKI

(Intentionally dropped @gmail.com recipients, as gmail refuses to
accept emaif from my email domain, unfortunately.)

Really OK?

I cannot find block_cloning in array *features_for_read[] of
stand/libsa/zfs/zfsimpl.c, which possibly mean boot codes (including
loader) cannot boot from Root-on-ZFS pool having block_cloning active.

Not sure adding '"com.fudosecurity:block_cloning",' here is sufficient
or not. Possibly more works are needed.

IMHO, all default-enabled features should be safe for booting.
Implement features with disalded, impement boot codes to support them,
then finally enable them by default should be the only valid route.


[1] https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c


On Mon, 18 Sep 2023 07:31:46 +0200
Martin Matuska  wrote:

> I vote for enabling block cloning on main :-)
> 
> mm
> 
> On 16. 9. 2023 19:14, Alexander Motin wrote:
> > On 16.09.2023 01:25, Graham Perrin wrote:
> >> On 16/09/2023 01:28, Glen Barber wrote:
> >>> o A fix for the ZFS block_cloning feature has been implemented.
> >>
> >> Thanks
> >>
> >> I see 
> >> ,
> >>  
> >> with 
> >> 
> >>  
> >> in stable/14.
> >>
> >> As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT 
> >> n265350-72d97e1dd9cc): should we assume that additional fixes, not 
> >> necessarily in time for 14.0-RELEASE, will be required before 
> >> vfs.zfs.bclone_enabled can default to 1?
> >
> > I am not aware of any block cloning issues now.  All this thread about 
> > bclone_enabled actually started after I asked why it is still 
> > disabled. Thanks to Mark Millard for spotting this issue I could fix, 
> > but now we are back at the point of re-enabling it again.  Since the 
> > tunable does not even exist anywhere outside of FreeBSD base tree, I'd 
> > propose to give this code another try here too.  I see no point to 
> > have it disabled at least in main unless somebody needs time to run 
> > some specific tests first.

-- 
Tomoaki AOKI

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-18 Thread Mark Johnston

On Mon, Sep 18, 2023 at 07:31:46AM +0200, Martin Matuska wrote:
> I vote for enabling block cloning on main :-)

Have you or anyone else run through the test suite with block cloning
enabled?

> On 16. 9. 2023 19:14, Alexander Motin wrote:
> > On 16.09.2023 01:25, Graham Perrin wrote:
> > > On 16/09/2023 01:28, Glen Barber wrote:
> > > > o A fix for the ZFS block_cloning feature has been implemented.
> > > 
> > > Thanks
> > > 
> > > I see 
> > > ,
> > > with 
> > > 
> > > in stable/14.
> > > 
> > > As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT
> > > n265350-72d97e1dd9cc): should we assume that additional fixes, not
> > > necessarily in time for 14.0-RELEASE, will be required before
> > > vfs.zfs.bclone_enabled can default to 1?
> > 
> > I am not aware of any block cloning issues now.  All this thread about
> > bclone_enabled actually started after I asked why it is still disabled.
> > Thanks to Mark Millard for spotting this issue I could fix, but now we
> > are back at the point of re-enabling it again.  Since the tunable does
> > not even exist anywhere outside of FreeBSD base tree, I'd propose to
> > give this code another try here too.  I see no point to have it disabled
> > at least in main unless somebody needs time to run some specific tests
> > first.
> > 
>

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-17 Thread Martin Matuska


I vote for enabling block cloning on main :-)

mm

On 16. 9. 2023 19:14, Alexander Motin wrote:

On 16.09.2023 01:25, Graham Perrin wrote:

On 16/09/2023 01:28, Glen Barber wrote:

o A fix for the ZFS block_cloning feature has been implemented.


Thanks

I see 
, 
with 
 
in stable/14.


As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT 
n265350-72d97e1dd9cc): should we assume that additional fixes, not 
necessarily in time for 14.0-RELEASE, will be required before 
vfs.zfs.bclone_enabled can default to 1?


I am not aware of any block cloning issues now.  All this thread about 
bclone_enabled actually started after I asked why it is still 
disabled. Thanks to Mark Millard for spotting this issue I could fix, 
but now we are back at the point of re-enabling it again.  Since the 
tunable does not even exist anywhere outside of FreeBSD base tree, I'd 
propose to give this code another try here too.  I see no point to 
have it disabled at least in main unless somebody needs time to run 
some specific tests first.

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-16 Thread Alexander Motin


On 16.09.2023 01:25, Graham Perrin wrote:

On 16/09/2023 01:28, Glen Barber wrote:

o A fix for the ZFS block_cloning feature has been implemented.


Thanks

I see 
, with  in stable/14.


As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT 
n265350-72d97e1dd9cc): should we assume that additional fixes, not 
necessarily in time for 14.0-RELEASE, will be required before 
vfs.zfs.bclone_enabled can default to 1?


I am not aware of any block cloning issues now.  All this thread about 
bclone_enabled actually started after I asked why it is still disabled. 
Thanks to Mark Millard for spotting this issue I could fix, but now we 
are back at the point of re-enabling it again.  Since the tunable does 
not even exist anywhere outside of FreeBSD base tree, I'd propose to 
give this code another try here too.  I see no point to have it disabled 
at least in main unless somebody needs time to run some specific tests 
first.


--
Alexander Motin

vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

2023-09-15 Thread Graham Perrin


On 16/09/2023 01:28, Glen Barber wrote:

o A fix for the ZFS block_cloning feature has been implemented.


Thanks

I see 
, 
with 
 
in stable/14.


As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT 
n265350-72d97e1dd9cc): should we assume that additional fixes, not 
necessarily in time for 14.0-RELEASE, will be required before 
vfs.zfs.bclone_enabled can default to 1?

FreeBSD 14.0-BETA2 Now Available

2023-09-15 Thread Glen Barber

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The second BETA build of the 14.0-RELEASE release cycle is now
available.

Installation images are available for:

o 14.0-BETA2 amd64 GENERIC
o 14.0-BETA2 i386 GENERIC
o 14.0-BETA2 powerpc GENERIC
o 14.0-BETA2 powerpc64 GENERIC64
o 14.0-BETA2 powerpc64le GENERIC64LE
o 14.0-BETA2 powerpcspe MPC85XXSPE
o 14.0-BETA2 armv7 GENERICSD
o 14.0-BETA2 aarch64 GENERIC
o 14.0-BETA2 aarch64 RPI
o 14.0-BETA2 aarch64 PINE64
o 14.0-BETA2 aarch64 PINE64-LTS
o 14.0-BETA2 aarch64 PINEBOOK
o 14.0-BETA2 aarch64 ROCK64
o 14.0-BETA2 aarch64 ROCKPRO64
o 14.0-BETA2 riscv64 GENERIC
o 14.0-BETA2 riscv64 GENERICSD

Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-BETA1 includes:

o The Areca RAID driver has been updated to version 1.50.00.06.

o The libarchive library has been updated.

o A fix for the ZFS block_cloning feature has been implemented.

o Several linux(4) updates.

o Several manual page updates.

A list of changes since 13.x is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-BETA2/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-BETA2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/BETA2
/aws/service/freebsd/amd64/base/zfs/14.0/BETA2

FreeBSD/arm64 EC2 AMIs are not available for this BETA build.

=== Vagrant Images ===

FreeBSD/amd64 images are not available for this BETA build.

=== Upgrading ===

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

Due to an issue where an existing file had been replaced by a directory
with the same name, binary upgrades from 13.2 and earlier using the 
freebsd-update(8) utility will not work.  The issue is being
investigated.

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-BETA2

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available) [block_cloning and zilsaxattr missing from loader's features_for_read]

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available) [block_cloning and zilsaxattr missing from loader's features_for_read]

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available) [block_cloning and zilsaxattr missing from loader's features_for_read]

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

FreeBSD 14.0-BETA2 Now Available

12 matches

Site Navigation

Mail list logo

Footer information