[PATCH] md-create: specify that the "chunk" parameter should be absent for RAID1
by Laszlo Ersek
Recently, mdadm has started (correctly) rejecting the "chunk" parameter
for RAID1; see e.g. <https://bugzilla.redhat.com/show_bug.cgi?id=1987170>.
Update the documentation accordingly, and in the mdadm test case, move the
"chunk:65536" parameter from a RAID1 creation command to a RAID5 one.
Suggested-by: Richard W.M. Jones <rjones(a)redhat.com>
Signed-off-by: Laszlo Ersek <lersek(a)redhat.com>
---
generator/actions_core.ml | 3 +++
tests/md/test-mdadm.sh | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/generator/actions_core.ml b/generator/actions_core.ml
index 226fb860a073..8884f358079b 100644
--- a/generator/actions_core.ml
+++ b/generator/actions_core.ml
@@ -6566,6 +6566,9 @@ If not set, this defaults to C<0>.
The chunk size in bytes.
+The C<chunk> parameter does not make sense, and should not be specified,
+when C<level> is C<raid1> (which is the default; see below).
+
=item C<level>
The RAID level, which can be one of:
diff --git a/tests/md/test-mdadm.sh b/tests/md/test-mdadm.sh
index b961581baf7d..fac6c27fdd25 100755
--- a/tests/md/test-mdadm.sh
+++ b/tests/md/test-mdadm.sh
@@ -63,13 +63,13 @@ part-add /dev/sdd p $p4_start $p4_end
# RAID 1.
md-create r1t1 "/dev/sda1 /dev/sdb1"
-md-create r1t2 "/dev/sdc1 /dev/sdd1" chunk:65536
+md-create r1t2 "/dev/sdc1 /dev/sdd1"
# RAID 5.
md-create r5t1 "/dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2" \
missingbitmap:0x10 nrdevices:4 spare:1 level:5
-md-create r5t2 "/dev/sda3 /dev/sdb3" missingbitmap:0x1 level:5
+md-create r5t2 "/dev/sda3 /dev/sdb3" missingbitmap:0x1 level:5 chunk:65536
md-create r5t3 "/dev/sdc3 /dev/sdd3" \
missingbitmap:0x6 nrdevices:2 spare:2 level:5
base-commit: 19cc3dbcc4c45a1f4afe188d2e2ef4f8de217963
--
2.19.1.3.g30247aa5d201
2 years, 5 months
[PATCH nbdkit 0/6] UNFINISHED Advertise block size constraints
by Richard W.M. Jones
Hi Eric,
This is is the sort of thing I'm thinking about. The last patch is
not complete.
The idea is that we add the simplest possible thing to the server:
Plugins get a new .block_size callback allowing them to advertise
minimum/preferred/maximum block size. This will cause an
NBD_INFO_BLOCK_SIZE message to be sent back to the client.
However nothing in the server enforces this. Badly sized/aligned
client requests will be passed through to the plugin.
To mitigate this, I added a new filter
(nbdkit-block-size-constraint-filter, please think of a better name!)
which can be used both as an easier way to set the constraints without
having to modify plugins, and also as a way to enforce various error
policies.
(The error policies are not implemented yet, but I've documented them).
Initially there would only be two policies:
- allow: Same as nbdkit server, allow anything.
- error: Send an error back to the client for malformed requests.
You could imagine other error policies here, such as enforcing only
the lower or upper bound.
For plugins that cannot handle unconstrained requests, but still want
to serve badly behaved clients, this is where the existing
nbdkit-blocksize-filter fits in nicely. We would probably need some
documentation on best practice ways to combine them which is not there
at the moment.
Of course clients (according to the spec) are not supposed to ignore
block size constraints, but, ummm, we know some that do :-(
Rich.
2 years, 5 months
libguestfs "test-mdadm.sh" and php tests failing?
by Laszlo Ersek
Hi,
on up-to-date Fedora 35, "test-mdadm.sh" in the libguestfs test suite is
failing like this:
*stdin*:32: libguestfs: error: md_create: mdadm: r1t2: mdadm: specifying
chunk size is forbidden for this level
I've searched the web for the error message, but only found
<https://bugzilla.redhat.com/show_bug.cgi?id=1984335>.
I don't recall this failure from earlier, so it must be something recent.
I think the error message may refer to the following command:
md-create r1t2 "/dev/sdc1 /dev/sdd1" chunk:65536
This command goes back to historical commit c11a92751e00 ("New API:
mdadm-create for creating MD devices.", 2011-11-11).
When I prepend SKIP_TEST_MDADM_SH=1 to the "make check" command line,
the next test that (unexpectedly) fails is "run-php-tests.sh". Please
see the log attached. And, I cannot set a SKIP variable for this test, I
think.
I'll go ahead and push the common submodule update anyways
(5b5fac3e0b10..41126802097f).
Thanks,
Laszlo
2 years, 5 months
[libguestfs-common PATCH 0/3] don't wrap log messages written to non-TTYs
by Laszlo Ersek
https://bugzilla.redhat.com/show_bug.cgi?id=1820221
The first patch turns "Std_utils.wrap" into an internal (not public)
function in "Tools_utils". This is doable after guestfs-tools commit
626f0441d251 ("virt-resize: replace "wrap" calls with calls to "info"",
2022-02-10).
The second patch causes "Tools_utils.wrap" not to wrap if the output is
going to a file descriptor that does not refer to a TTY.
The third patch introduces the "-w" / "--wrap" option, for forcing the
previous behavior (making a difference only on non-TTYs). This follows
the "--colours" option's example, and if accepted, will require
documentation updates in guestfs-tools and virt-v2v.
Thanks,
Laszlo
Laszlo Ersek (3):
Demote "Std_utils.wrap" to an internal function in Tools_utils
Tools_utils.wrap: only wrap text for TTYs
add common ("standard") option -w / --wrap
mlstdutils/std_utils.ml | 44 +++++++---------------------------------
mlstdutils/std_utils.mli | 9 ++++----
mltools/test-getopt.sh | 2 ++
mltools/tools_utils.ml | 41 +++++++++++++++++++++++++++++++++++++
4 files changed, 54 insertions(+), 42 deletions(-)
base-commit: 5b5fac3e0b10ff4c5fd28eaa5f17ba0c163dc49b
--
2.19.1.3.g30247aa5d201
2 years, 5 months
[PATCH nbdkit] tls-fallback: Always call next open function
by Richard W.M. Jones
This fixes a crash when using --filter=tls-fallback. It happens to
only occur with my block_size patch series and is easily reproducible
(see commit message). I believe the problem is generic although I
couldn't work out how to trigger in unpatched nbdkit.
tls-fallback filter has a scary comment which seems to indicate that
calling the next open is wrong (unsafe?) in the !tls case. So I don't
know if this change is really right.
Rich.
2 years, 5 months
Re: [Libguestfs] opensuse 15.2 and yescrypt
by Frédéric Pierret
Le 2/16/22 à 17:51, Frédéric Pierret a écrit :
> Hi,
>
> I've been investigating a recent issue I had between libguestfs 1.44 and 1.47 about setting root password for an openSUSE 15.2 guest VM.
>
> On libguestfs 1.44, default hash method for setting root password is SHA512 where as with recent commit for 1.47 it uses YESCRYPT (https://github.com/rwmjones/guestfs-tools/commit/ba6d4cb7d394c1b5d14ef810...).
>
> Looking at https://build.opensuse.org/package/show/openSUSE%3AFactory/libxcrypt it looks like I would need to install libxcrypt into the guest but I don't find any official package for Leap.
>
> What workaround would you suggest instead? For now, the only workaround I see if to manually generate the password and sed the shadow file.
>
> Thank you.
>
> Best regards,
> Frédéric Pierret
>
> PS: You can reach me also with my Qubes OS email: frederic.pierret(a)qubes-os.org.
Adding the list, I've made a mistake in the CC field sorry.
Best,
Frédéric
2 years, 5 months
Re: [Libguestfs] guestfish with support Microsoft ReFS
by Richard W.M. Jones
On Wed, Feb 16, 2022 at 01:51:51PM +0100, Gottschalk wrote:
> i asked you to support Microsoft ReFS in guestfish some weeks ago.
>
> You answered me, it is easy to integrate another fs-driver into guestfish.
>
> So i have a propriate driver from paragon-software, which you can integrate.
>
> Is it possible to do this?
It should be straightforward. ISTR it's a kernel module, so it should
just work. Once the kernel on the host has been updated, libguestfs
will pull in the kernel module into the libguestfs appliance, and in
theory ReFS filesystems would be immediately mountable.
If their software also has extra tools - for example mount.refs to
create filesystems - then a small change would need to be made in
/usr/lib64/guestfs/supermin.d to copy those tools into the appliance.
But this should also be straightforward. Does it come with tools?
Are they packaged as a distro package?
> If yes i will inform Paragon-Software to contact you directly.
I'm not so interested in talking about proprietary software with them.
I can give general advice however.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2 years, 5 months
[PATCH libnbd v2 0/9] golang: Safer, easier to use, and faster AioBuffer
by Nir Soffer
Improve AioBuffer to make it safer, easier to use, and faster when integrating
with other Go APIs.
New Go specific APIs:
- MakeAioBufferZero() - creates a new buffer using calloc(), to make it easy
and efficient to use a zeroed buffer.
- AioBuffer.Slice() - create a slice backed by the underlying buffer without
copying the contents of the buffer.
Performance improments:
- FromBytes() is 3 time faster
- Code using Bytes() should use Slice() now. aio_copy example shows up to 260%
speedup.
Improve testing:
- New AioBuffer tests
- New AioBuffer benchmarks
Documention:
- AioBuffer is fully documnted now.
Changes since v1:
- Rename the new test to libnbd_020_ to match the current test numbering
semantics (Eric)
- We run the benchmarks in make check using very short timeout to keep them
working without overloading the CI. (Eric)
- Update copyright year (Eric)
- Fix many typos in comments and commit messages (Eric)
v1 was here:
https://listman.redhat.com/archives/libguestfs/2022-January/msg00218.html
Nir Soffer (9):
golang: tests: Add test for AioBuffer
golang: aio_buffer.go: Make it safer to use
golang: aio_buffer.go: Add missing documentation
golang: aio_buffer.go: Add MakeAioBufferZero()
golang: aio_buffer.go: Add Slice()
golang: tests: Use AioBuffer.Slice()
golang: aio_buffer.go: Speed up FromBytes()
golang: aio_buffer.go: Benchmark copy flows
golang: examples: aio_copy: Simplify using AioBuffer
golang/Makefile.am | 1 +
golang/aio_buffer.go | 39 ++++-
golang/examples/aio_copy/aio_copy.go | 29 +---
golang/libnbd_020_aio_buffer_test.go | 236 +++++++++++++++++++++++++++
golang/libnbd_500_aio_pread_test.go | 2 +-
golang/libnbd_510_aio_pwrite_test.go | 8 +-
golang/run-tests.sh | 5 +
7 files changed, 286 insertions(+), 34 deletions(-)
create mode 100644 golang/libnbd_020_aio_buffer_test.go
--
2.34.1
2 years, 5 months