similar to: do_umount adjustment

Add a macro STRDUP_RESOLVE_DEVICE_OR_PATH to resolve path or device. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/daemon.h | 16 ++++++++++++++++ daemon/mount.c | 13 ++----------- 2 files changed, 18 insertions(+), 11 deletions(-) diff --git a/daemon/daemon.h b/daemon/daemon.h index 85eec45..f7d0c75 100644 --- a/daemon/daemon.h +++ b/daemon/daemon.h @@ -336,6

Add the option force and lazy for force and lazy umount. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/mount.c | 25 +++++++++++++++++++++++-- generator/generator_actions.ml | 23 ++++++++++++----------- gobject/Makefile.inc | 2 ++ po/POTFILES | 1 + 4 files changed, 38 insertions(+), 13 deletions(-) diff --git

Add the option force and lazy for force and lazy umount. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/mount.c | 25 +++++++++++++++++++++++-- generator/generator_actions.ml | 23 ++++++++++++----------- gobject/Makefile.inc | 2 ++ po/POTFILES | 1 + 4 files changed, 38 insertions(+), 13 deletions(-) diff --git

Add a macro DUP_RESOLVE_DEVICE_OR_PATH to resolve path or device. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/daemon.h | 18 ++++++++++++++++++ daemon/mount.c | 13 ++----------- po/POTFILES | 8 ++++++++ 3 files changed, 28 insertions(+), 11 deletions(-) diff --git a/daemon/daemon.h b/daemon/daemon.h index 85eec45..39cc3f3 100644 --- a/daemon/daemon.h +++

This started as a simple warning-elimination change. I'll get back to that series shortly ;-) It turned into a factorization and constification exercise during which I got a taste of ocaml. Thanks to Rich Jones for help with a few snippets in generator.ml. The overall result is that many previously-manually-maintained bits from daemon/*.c functions are now hoisted into the automatically-

For Device parameters we expect a block device name. However we were only testing for "/dev/..." and so chardevs (from the appliance) could be passed here, resulting in strange effects. This adds a function is_device_parameter which tests for a valid block device name. For Dev_or_Path parameters much the same, except we can also use the is_device_parameter function elsewhere in the

This type is initially identical to Device. --- generator/bindtests.ml | 2 +- generator/c.ml | 7 +++++-- generator/csharp.ml | 6 ++++-- generator/daemon.ml | 4 ++-- generator/erlang.ml | 6 +++--- generator/fish.ml | 8 ++++---- generator/gobject.ml | 11 ++++++----- generator/haskell.ml | 11 +++++++---- generator/java.ml | 10 +++++-----

On 2/24/23 2:54 PM, Joseph Qi wrote: > I can reproduce this in my local VM. > I've traced ocfs2_dismount_volume and found that it hasn't been called. > So EBUSY is returned in VFS layer. I guess something wrong when doing > a copy with linked SQEs (normal copy seems no problem). > I am inclined to agree with you. I also test liburing examples apps on ext4 partition,

On 2/24/23 3:48 PM, Heming Zhao via Ocfs2-devel wrote: > On 2/24/23 2:54 PM, Joseph Qi wrote: >> I can reproduce this in my local VM. >> I've traced ocfs2_dismount_volume and found that it hasn't been called. >> So EBUSY is returned in VFS layer. I guess something wrong when doing >> a copy with linked SQEs (normal copy seems no problem). >> > > I am

On 2/24/23 3:52 PM, Joseph Qi wrote: > > > On 2/24/23 3:48 PM, Heming Zhao via Ocfs2-devel wrote: >> On 2/24/23 2:54 PM, Joseph Qi wrote: >>> I can reproduce this in my local VM. >>> I've traced ocfs2_dismount_volume and found that it hasn't been called. >>> So EBUSY is returned in VFS layer. I guess something wrong when doing >>> a copy

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

On 2/24/23 4:03 PM, Heming Zhao wrote: > On 2/24/23 3:52 PM, Joseph Qi wrote: >> >> >> On 2/24/23 3:48 PM, Heming Zhao via Ocfs2-devel wrote: >>> On 2/24/23 2:54 PM, Joseph Qi wrote: >>>> I can reproduce this in my local VM. >>>> I've traced ocfs2_dismount_volume and found that it hasn't been called. >>>> So EBUSY is

https://bugzilla.redhat.com/show_bug.cgi?id=1477623 The first two patches are cleanups. The third patch changes the way that we handle Device and Dev_or_Path parameters so that a parameter marked as such can really only contain a block device name (and not, for instance, a chardev). Using a chardev here caused hangs in the API. The next two patches fix API usage to conform to this new stricter

Some of the oldest and most core APIs, reimplemented. This also moves the strange ‘mount_vfs_nochroot’ function into btrfs.c. --- daemon/Makefile.am | 2 + daemon/btrfs.c | 43 ++++++++++++++++++++ daemon/daemon.h | 6 --- daemon/mount.c | 99 ----------------------------------------------- daemon/mount.ml | 62 +++++++++++++++++++++++++++++

On 2/26/23 11:22 PM, Heming Zhao wrote: > On Sun, Feb 26, 2023 at 04:45:44PM +0800, Heming Zhao via Ocfs2-devel wrote: >> On Fri, Feb 24, 2023 at 06:59:47PM +0800, Joseph Qi wrote: >>> >>> >>> On 2/24/23 4:03 PM, Heming Zhao wrote: >>>> On 2/24/23 3:52 PM, Joseph Qi wrote: >>>>> >>>>> >>>>> On 2/24/23 3:48

Hi List, I had a need recently to efficiently synchronise between some large LUNs (boot drive disks) at two different datacentres. Solutions like drbd and $proprietary_array_vendors_software were overkill - we only needed (wanted!) to periodically synchronise these LUNs whenever major changes were generated on the source. On the other hand however, re-sending the entire disk contents each time

On Fri, Feb 24, 2023 at 06:59:47PM +0800, Joseph Qi wrote: > > > On 2/24/23 4:03 PM, Heming Zhao wrote: > > On 2/24/23 3:52 PM, Joseph Qi wrote: > >> > >> > >> On 2/24/23 3:48 PM, Heming Zhao via Ocfs2-devel wrote: > >>> On 2/24/23 2:54 PM, Joseph Qi wrote: > >>>> I can reproduce this in my local VM. > >>>>

The series below makes changes like these mechanically, one class of change per change-set: strcmp(...) == 0 to STREQ(...) strcmp(...) != 0 to STRNEQ(...) strncmp(...) == 0 to STREQLEN(...) strncmp(...) != 0 to STRNEQLEN(...) strcasecmp(...) == 0 to STRCASEEQ(...) strcasecmp(...) != 0 to STRCASENEQ(...) strncasecmp(...) == 0 to STRCASEEQLEN(...)

On Sun, Feb 26, 2023 at 04:45:44PM +0800, Heming Zhao via Ocfs2-devel wrote: > On Fri, Feb 24, 2023 at 06:59:47PM +0800, Joseph Qi wrote: > > > > > > On 2/24/23 4:03 PM, Heming Zhao wrote: > > > On 2/24/23 3:52 PM, Joseph Qi wrote: > > >> > > >> > > >> On 2/24/23 3:48 PM, Heming Zhao via Ocfs2-devel wrote: > > >>> On

My apologies if this isn't the correct posting address -- I didn't see an obvious "report problems here" on the website. Some of the code modifications introduced between 2.2.7 and 2.2.8 don't appear to agree with Solaris, using Sun's CC, with the LDAP support code. Note that I'm linking against the Solaris-bundled LDAP package (SUNWlldap). |% env