please explain ...

[Holm Tiffe]

Tomohiro Kusumi wrote:

> Aaron LI <aly at aaronly.me>:
> >
> > On Thu, 19 Jul 2018 15:16:46 +0200
> > Holm Tiffe <holm at freibergnet.de> wrote:
> >
> > > Tomohiro Kusumi wrote:
> > >
> > > >  Aaron LI <aly at aaronly.me>:
> > > > >
> > > > > On Thu, 19 Jul 2018 11:39:06 +0200
> > > > > Holm Tiffe <holm at freibergnet.de> wrote:
> > > > >
> > > > > Hi Holm,
> > > > >
> > > > > Thanks for trying DFly :)
> > > > >
> > > > > > Jul 19 11:12:34 fly kernel: [drm] fb depth is 24
> > > > > > Jul 19 11:12:34 fly kernel: [drm]    pitch is 5888
> > > > > > Jul 19 11:12:34 fly kernel: drm0: debug: Error during ACPI methods
> > > > > > call Jul 19 11:12:34 fly kernel: [drm] Initialized radeon 2.40.0
> > > > > > 20080528 Jul 19 11:12:34 fly kernel: md3: Malloc disk
> > > > > > Jul 19 11:12:34 fly kernel: md4: Malloc disk
> > > > > > Jul 19 11:12:35 fly kernel: md5: Malloc disk
> > > > > > Jul 19 11:12:35 fly kernel: md6: Malloc disk
> > > > > > Jul 19 11:12:35 fly kernel: md7: Malloc disk
> > > > > > Jul 19 11:12:40 fly kernel: md8: Malloc disk
> > > > > > Jul 19 11:12:50 fly kernel: md9: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md10: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md11: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md12: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md13: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md14: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md15: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md16: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md17: Malloc disk
> > > > > > Jul 19 11:12:51 fly kernel: md18: Malloc disk
> > > > > > Jul 19 11:12:57 fly kernel: pid 1305 (at-spi-bus-launc), uid 201:
> > > > > > exited on signal 11
> > > > > >
> > > > > > ..what those inflationary appearing malloc disks are good for:
> > > > >
> > > > > The "md" device uses an "almost cloning" method, i.e., when /dev/md{N}
> > > > > is opened, a /dev/md{N+1} device is auto created.
> > > > >
> > > > > I think there is something wrong with the md probe... but I don't have
> > > > > more ideas here.
> > > >
> > > > This is a known behavior which originates from FreeBSD.
> > > > https://github.com/freebsd/freebsd/commit/1624e20f39888e846831b8a8457c919d0cfa54c9
> > > >
> > > > I doubt anyone or any userspace program needs this behavior.
> > >
> > > Hmm.
> > >
> > > May be..but I'm using FreeBSD since before 2.0 and I never ever saw an
> > > behavior like this.
> > >
> > > Yes I'm used malloc disks on this Notebook once, but I never created more
> > > as two of them and I've deallocated them cleanly, there is no need to
> > > create additional ones every time...
> >
> > Yes, I think you're having a problem with "md" here, but the information you
> > provided here is not enough for me and other devs to identify the problem.
> 
> This behavior is just generally bothering and unneeded.
> 
> We do have code that works around this too.
> https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/etc/autofs/special_media#L12
> 
> Above workaround code is actually just creating another bug, by not
> supporting /dev/mdX, only to avoid creating a new /dev/md(X+1) for no
> reason.
> I may someday fix this, so that I can remove this XXX stuff which only
> exists in DragonFly autofs implementation.
> 
> >
> > Could you describe in more details how you used "md" here?  When the above
> > "md" messages and errors happen?  etc.
> >
> >
> > Cheers,
> > --
> > Aaron

I've dd'ed an Win95 Disk Drive to the filesystem for backup purposes (the
disk came from an industrial controller wich died with an defective
Mainboard),  copied the disk dump, mounted is as memory disc containing
msdosfs and copied some driver stuff to that memory disk more than once.
Later I've dumped that stuff to another disk wich got mounted to another
computer and is controlling the production process of Glass Windows now.

... but I'm not sure anymore if I actually used md disks or vn disks,
since I can't find an mdconfig in DFLY but an vnconfig, and mdconfig in
FreeBSD which has the functionality of vnconfig in DFLY.. sorry.


The interesting thing is that I have now, after an reboot of the DFLY
Laptop only this:

$ ls -l /dev/vn*
crw-r-----  1 root  operator    5, 0xffff00ff 19-Jul-2018 19:01 /dev/vn
crw-r-----  1 root  operator    5, 0x1e110007 19-Jul-2018 19:01 /dev/vn0
crw-r-----  1 root  operator    5, 0x1e11000f 19-Jul-2018 19:01 /dev/vn1
crw-r-----  1 root  operator    5, 0x1e110017 19-Jul-2018 19:01 /dev/vn2
crw-r-----  1 root  operator    5, 0x1e11001f 19-Jul-2018 19:01 /dev/vn3
$ ls -l /dev/md*
crw-r-----  1 root  operator    7, 0x1e110007 19-Jul-2018 19:01 /dev/md0
crw-r-----  1 root  operator    7, 0x1e100007 19-Jul-2018 19:01
/dev/md0s0
crw-r-----  1 root  operator    7, 0x1e11000f 19-Jul-2018 17:02 /dev/md1
crw-r-----  1 root  operator    7, 0x1e10000f 19-Jul-2018 17:02
/dev/md1s0

..so now only two md disks getting configured..but it is more than a
month ago since I've used one of them and rebooted many times since
then.

What the heck is going on here?

Regards,

Holm



-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
info at tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741