ils, and that will probably require having my generator read
/etc/fstab and duplicate the work of fstab-generator.c
If the documentation is wrong, and the code is correct, would it be
possible to get "AfterMountsFor=" as that is the functionality that I
really want.
Thanks,
NeilBrown
On Mon, Jan 23 2017, Andrei Borzenkov wrote:
> This was discussed just recently as regression in Leap 42.2 on opensuse
> mailing list ...
>
> 23.01.2017 03:13, NeilBrown пишет:
>>
>> hi,
>> according to "man systemd.unit" :
>>
>>Requ
tual-block-md0, it
mentions /dev/md0.
How does systemd know about /dev/md0, or the connection it has with
sys-devices-virtual-block-md0 ??
Does
systemctl list-dependencies sys-devices-virtual-block-md0.device
report anything interesting? I get
sys
On Mon, Jan 30 2017, Andrei Borzenkov wrote:
> 30.01.2017 04:53, NeilBrown пишет:
>> On Fri, Jan 27 2017, Andrei Borzenkov wrote:
>>
>>> 26.01.2017 21:02, Luke Pyzowski пишет:
>>>> Hello,
>>>> I have a large RAID6 device with 24 local drives on C
On Mon, Jan 30 2017, Andrei Borzenkov wrote:
> On Mon, Jan 30, 2017 at 9:36 AM, NeilBrown wrote:
> ...
>>>>>>
>>>>>> systemd[1]: Created slice system-mdadm\x2dlast\x2dresort.slice.
>>>>>> systemd[1]: Starting system-mdadm\x2dlast\x2
d is
> condition "array is active".
Of course, you are right.
A suitable "array is active" test is the existence of
.../md/sync_action
which appears when an array is activated (except for RAID0 and Linear,
which don't need last-resort support).
So this is what I propo
requires/foo.mount symlink to be
remote-fs.target.requires/foo.automount would be problematic though.
Could we teach systemd-fstab-generator to ignore $TYPE filesystems
if TYPE-fstab-generator existed?
Or should we just build all this filesystem-specific knowledge into
systemd?
Thanks fo
On Mon, May 29 2017, Lennart Poettering wrote:
> On Fri, 26.05.17 12:46, NeilBrown (ne...@suse.com) wrote:
>
>>
>> Hi all,
>> it appears that systemd doesn't play well with NFS "bg" mounts.
>> I can see a few options for how to address this and wo
Systemd does not, and will not, support "bg" correctly.
It has other, better, ways to handle "background" mounting.
Explain this.
See also https://github.com/systemd/systemd/issues/6046
Signed-off-by: NeilBrown
---
utils/mount/nfs.man | 18 +-
1 file ch
On Tue, May 30 2017, Michael Biebl wrote:
> 2017-05-30 0:19 GMT+02:00 NeilBrown :
>
>> +.B bg
>> +option is not supported, and may be stripped from the option list.
>
> Either systemd is updated to actually strip the bg option or not. The
> documentation should refle
On Tue, Jun 06 2017, Steve Dickson wrote:
> Hello,
>
> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>
>> Systemd does not, and will not, support "bg" correctly.
>> It has other, better, ways to handle "background" mounting.
> The only problem with
On Wed, Jun 07 2017, Steve Dickson wrote:
> On 06/07/2017 08:02 AM, Lennart Poettering wrote:
>> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
>>
>>>
>>>
>>> On 06/06/2017 05:49 PM, NeilBrown wrote:
>>>> On T
On Thu, Jun 08 2017, J. Bruce Fields wrote:
> On Thu, Jun 08, 2017 at 03:16:52PM +1000, NeilBrown wrote:
>> So I think I've found a solution for systemd to handle "bg" nfs mounts
>> correctly. I'll submit some pull requests for consideration.
>
> Out
On Tue, May 30 2017, NeilBrown wrote:
> Systemd does not, and will not, support "bg" correctly.
> It has other, better, ways to handle "background" mounting.
For those who aren't closely watching systemd development, a
patch was recently accepted which causes sys
On Mon, Jul 10 2017, Steve Dickson wrote:
> Hey Neil,
>
> On 07/04/2017 06:20 PM, NeilBrown wrote:
>> On Tue, May 30 2017, NeilBrown wrote:
>>
>>> Systemd does not, and will not, support "bg" correctly.
>>> It has other, better, ways to handle &
MNT_FORCE does not allow a busy filesystem to be unmounted. Only
MNT_DETACH allows that.
MNT_FORCE only tries to abort pending transactions, in the hope that
might help umount not to block,
Also, other filesystems than NFS support MNT_FORCE.
Signed-off-by: NeilBrown
---
Explanation derived
ns
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=3892174834ea1a4729348f0ecd3078cc1d5458e4
If you have a file /etc/nfs.conf which contains
[general]
pipefs-directory = /run/nfs/rpc-pipefs
then a generator will create the required .mount unit, and all
tools and daemons will know where to look for the filesystem
have a minor number >=512 and are not
auto-re-created if the device node is re-opened before udev unlinks it.
So: the patch might be safe, and might solve a particular problem, but
it is really just a bandaid. The best fix is "CREATE named=yes" (and
use named like "md_hom
g the companion
>> to 'DELETE'). However, later the 'ONLINE' got modified to 'CHANGE',
>> and the 'OFFLINE' got dropped completely.
>> Or that was the plan.
>> So it looks as if the conversion to 'CHANGE' got applied to the
>> 'OFFLINE' event, too.
>> Hence I strongly recommend to drop it completely, and let the kernel
>> or the MD module decide if and when a uevent should be send.
>
> I am totally fine with this, however we should make mdadm fail if run
> against a pre-2.6.28 kernel then.
>
> Cheers,
> Jes
I would suggest protecting the
if (fd >= 0)
ioctl(fd, BLKRRPART, 0);
if (mdi)
sysfs_uevent(mdi, "change");
code with
if (get_linux_version() < 2006028)
That should be completely safe - 2.6.28 and later do this (if needed).
NeilBrown
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
e
and the array will become inactive, but no uevent will be generated,
which isn't good.
Maybe send the uevent that was just removed from the 'inactive' case of
array_state_store() instead.
(But I still think this is just a bandaid and doesn't provide
On Wed, Feb 17 2016, Sebastian Parschauer wrote:
> On 16.02.2016 21:43, NeilBrown wrote:
>> On Wed, Feb 17 2016, Shaohua Li wrote:
>>
>>> On Tue, Feb 16, 2016 at 03:44:36PM +0100, Sebastian Parschauer wrote:
>>>> When stopping an MD device, then its devic
On Thu, Feb 18 2016, Hannes Reinecke wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/17/2016 10:29 PM, NeilBrown wrote:
>> On Thu, Feb 18 2016, Shaohua Li wrote:
>>
>>> On Wed, Feb 17, 2016 at 05:25:00PM +0100, Sebastian
>>> Parscha
ession
> > control group:
>
> Are you suggesting that mdadm forks off mdmon from within the user
> session? This is horribly ugly and broken and they shouldn't do that.
What alternative would you suggest?
A daemon needs to be running while certain md array
done by any tools, only by the kernel itself. It
> should probably be disabled by default.
I agree that instantiating on open is an unfortunate design, but it has been
around for a long time so we cannot just ignore it or turn it off.
I have a new approach to creating md device which we might eventu
systemd either.
So: how can I fit this need for "run some command on device timeout which
might be successful in activating the device"?
Alternately, is there some "all devices have been probed, nothing new will
appear unless it is hot-plugged" event. That would be equally
On Tue, 12 Nov 2013 00:10:28 -0800 Greg KH wrote:
> On Tue, Nov 12, 2013 at 11:31:45AM +1100, NeilBrown wrote:
> > Alternately, is there some "all devices have been probed, nothing new will
> > appear unless it is hot-plugged" event. That would be equally useful (and
On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH wrote:
> On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
> > On Tue, 12 Nov 2013 00:10:28 -0800 Greg KH
> > wrote:
> >
> > > On Tue, Nov 12, 2013 at 11:31:45AM +1100, NeilBrown wrote:
> > > > Al
On Tue, 12 Nov 2013 03:03:44 +0100 (CET) Jan Engelhardt
wrote:
>
> On Tuesday 2013-11-12 01:31, NeilBrown wrote:
> >
> >mdadm is quite good at assembling arrays incrementally. "udev" runs
> >"mdadm -I" for each new device and mdadm gathers them int
On Tue, 12 Nov 2013 14:52:43 +0100 Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Nov 12, 2013 at 09:17:19PM +1100, NeilBrown wrote:
> > On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH
> > wrote:
> > > Not for USB, sorry.
> > >
> > > The USB bus just announc
On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov
wrote:
> В Tue, 12 Nov 2013 21:17:19 +1100
> NeilBrown пишет:
>
> > On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH
> > wrote:
> >
> > > On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
> > &
On Tue, 12 Nov 2013 18:49:34 +0100 Colin Guthrie wrote:
> 'Twas brillig, and NeilBrown at 12/11/13 11:17 did gyre and gimble:
> > On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH
> > wrote:
> >
> >> On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
>
On Wed, 13 Nov 2013 22:11:27 +0600 "Alexander E. Patrakov"
wrote:
> 2013/11/13 NeilBrown :
> > On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov
> > wrote:
> >
> >> В Tue, 12 Nov 2013 21:17:19 +1100
> >> NeilBrown пишет:
> >>
> &
On Thu, 14 Nov 2013 11:23:30 +0600 "Alexander E. Patrakov"
wrote:
> NeilBrown пишет:
> > On Wed, 13 Nov 2013 22:11:27 +0600 "Alexander E. Patrakov"
> > wrote:
> >
> >> 2013/11/13 NeilBrown :
> >>> On Tue, 12 Nov 2013 19:01:49 +0
On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov
wrote:
> В Tue, 12 Nov 2013 21:17:19 +1100
> NeilBrown пишет:
>
> > On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH
> > wrote:
> >
> > > On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
> > &
entioned their appears to be present in 208.
I added some extra tracing, and it is definitely sending SIGTERM (but not
SIGHUP) to the "/usr/lib/systemd/systemd --user" but that process sometimes
doesn't die until the SIGKILL is sent.
Any idea what is happening, or how I
we fail to read
> the database with the currently created symlinks?
>
> The udev_device_new_from_syspath() is a public API from libudev. We
> should probably not change that and not allow other tools than udev
> itself, to create device structures for devices which are not around
&
pid to some magic file that 'ignore_proc' already knows about?
Ultimately we probably want to get udev to start mdmon for us and have
mdadm notice and not start it itself.
We also need to get udev to notice arrays that are being reshaped and to
start the mdadm which montiors the resh
impler to just SIGTERM mdmon and wait for it.
>
> We actually try to disassemble md already, i.e. we call the
> DM_DEV_REMOVE ioctl for all left-over devices. I am not really
> interested to link against libdm itself.
:-)
I get used to this .. people confusing md and dm, people confu
On Wed, 2 Nov 2011 02:16:15 +0100 Lennart Poettering
wrote:
> On Wed, 02.11.11 11:44, NeilBrown (ne...@suse.de) wrote:
>
> > > We nowadays jump back into the initrd when we shut down, so that the
> > > initrd disassembles everything it assembled at boot time. This
On Wed, 2 Nov 2011 14:32:25 +0100 Lennart Poettering
wrote:
> On Wed, 02.11.11 13:03, NeilBrown (ne...@suse.de) wrote:
> > Each instance of mdmon manages a set of arrays and must remain running
> > until all of those arrays are readonly (or shut down). This allows it to
>
On Mon, 7 Nov 2011 04:42:54 +0100 Kay Sievers wrote:
> On Mon, Nov 7, 2011 at 03:52, NeilBrown wrote:
>
> > However there is an important piece missing. When you remount,ro a
> > filesystem, the block device doesn't get told so it thinks it is still open
> > r
41 matches
Mail list logo
