Hallo,
if I''ve understood some mails in this list correct, then btrfs needs a
character device "btrfs-control" with the ID 10:55
When I look for this device in
/sys/class/misc/btrfs-control/dev
I see 10:234
And when I run the command
mkfs.btrfs -d raid0 -m raid1 /dev/sda1 /dev/sdc1
I get the error messages
failed to open /dev/btrfs-control skipping device registration
---
ls -l /dev/bt*
shows
crw-rw-rw- 1 root root 10,55 2. Apr 17:55 /dev/btrfs-control
---
Kernel 2.6.38.1 (self made), no udev, no initrd, no tempfs. btrfs from
nov. 2010
What goes wrong?
Viele Gruesse!
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Apr 02, 2011 at 06:45:00PM +0200, Helmut Hullen wrote:> if I''ve understood some mails in this list correct, then btrfs needs a > character device "btrfs-control" with the ID 10:55 > > When I look for this device in > > /sys/class/misc/btrfs-control/dev > > I see 10:234 > Kernel 2.6.38.1 (self made), no udev, no initrd, no tempfs. btrfs from > nov. 2010 > What goes wrong?No udev is wrong. Modern Linux kernels allocate minor devices dynamically. If you do not use udev, you need to synchronise /dev/ node with /sys/class/misc/btrfs-control/dev manually on each boot. -- Tomasz Torcz ,,(...) today''s high-end is tomorrow''s embedded processor.'''' xmpp: zdzichubg@chrome.pl -- Mitchell Blank on LKML -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Tomasz, Du meintest am 02.04.11:> No udev is wrong.Sorry - no. On the machines I use I don''t need udev (they are a kind of server, not end user workstations with often changing hardware). And I could abstain (? - please excuse my gerlish) from btrfs, but not from fixed device names. I may not believe that btrfs only works under udev.> Modern Linux kernels allocate minor devices > dynamically. If you do not use udev, you need to synchronise /dev/ > node with /sys/class/misc/btrfs-control/dev manually on each boot.How and where? From where gets the system the actual minor number 234 instead of the defined number 55? By the way - the btrfs module is "builtin", is that a problem? Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/02/2011 06:45 PM, Helmut Hullen wrote:> Hallo, > > if I''ve understood some mails in this list correct, then btrfs needs a > character device "btrfs-control" with the ID 10:55 > > When I look for this device in > > /sys/class/misc/btrfs-control/dev > > I see 10:234 > > And when I run the command > > mkfs.btrfs -d raid0 -m raid1 /dev/sda1 /dev/sdc1 > > I get the error messages > > failed to open /dev/btrfs-control skipping device registration > > --- > > ls -l /dev/bt* > > shows > > crw-rw-rw- 1 root root 10,55 2. Apr 17:55 /dev/btrfs-control > > --- > > Kernel 2.6.38.1 (self made), no udev, no initrd, no tempfs. btrfs from > nov. 2010 > > What goes wrong?As wrote by Tomasz the minor number of the btrfs-control is allocated dynamically. A lot of drivers create a device which is registered dynamically in the "misc" group. In linux this is a well established behavior from a long time. If you don''t want to use udev you have two choices: - use devtmpfs - create manually a device. But nobody guarantee that the minor/major will not change.> > > Viele Gruesse! > Helmut > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > . >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Goffredo Baroncelli wrote:> If you don''t want to use udev you have two choices: > - use devtmpfs > - create manually a device. But nobody guarantee that the minor/major > will not change.- use a udev replacement intended for embedded systems, such as mdev //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Goffredo, Du meintest am 03.04.11:>> if I''ve understood some mails in this list correct, then btrfs needs >> a character device "btrfs-control" with the ID 10:55 >> >> When I look for this device in >> >> /sys/class/misc/btrfs-control/dev >> >> I see 10:234> As wrote by Tomasz the minor number of the btrfs-control is allocated > dynamically.At which place?> If you don''t want to use udev you have two choices: > - use devtmpfsThat leads to similar problems as "udev": I have to define on another place ("/lib/udev/devices") the desired device.> - create manually a device. But nobody guarantee that the minor/major > will not change.That seems to be the behaviour I''m watching on my test machine. "hard coded" device with 10:55, but the system uses 10:234 If btrfs is designed to work only under udev then it has to check wether udev is running. Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Peter, Du meintest am 03.04.11:>> If you don''t want to use udev you have two choices: >> - use devtmpfs >> - create manually a device. But nobody guarantee that the >> minor/major will not change.> - use a udev replacement intended for embedded systems, such as mdevhttp://wildanm.wordpress.com/2007/08/21/mdev-mini-udev-in-busybox/ http://tinderbox.dev.gentoo.org/misc/mdev.conf I''ll take a try - thank you! Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Tomasz, Du meintest am 02.04.11:>> if I''ve understood some mails in this list correct, then btrfs needs >> a character device "btrfs-control" with the ID 10:55 >> >> When I look for this device in >> >> /sys/class/misc/btrfs-control/dev >> >> I see 10:234> If you do not use udev, you need to synchronise /dev/ > node with /sys/class/misc/btrfs-control/dev manually on each boot.Solved (something like reverse engineering). I re-create the (permanent) entry /dev/btrfs-control using the actual contents of "/sys/class/misc/btrfs-control/dev", and btrfs is happy (and me too). Works now on two of my machines for the next long time test ... ------------------ I''ll watch who changes the data ... some part of some program must have defined 234 as minor ID. Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Helmut, On 04/03/2011 05:11 AM, Helmut Hullen wrote:> Hallo, Goffredo,[..]>> As wrote by Tomasz the minor number of the btrfs-control is allocated >> dynamically. > > At which place?I replied you too fast. Btrfs register a "misc" device, but its number is not dynamically allocated (see [1] for further information), but it is static. $ grep BTRFS_MINOR -r include/ include/linux/miscdevice.h:#define BTRFS_MINOR 234 I can conclude that _now_ the minor is 234 and not 55. But I don''t know if it is a _stable_ interface. I think that during the boot you should check the minor with grep btrfs-control /proc/misc | awk ''{ print $1 }'' Regards G.Baroncelli [1] http://www.linuxjournal.com/article/2920> > Viele Gruesse! > Helmut > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > . >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Goffredo, Du meintest am 03.04.11:>>> As wrote by Tomasz the minor number of the btrfs-control is >>> allocated dynamically.>> At which place?> I replied you too fast. Btrfs register a "misc" device, but its > number is not dynamically allocated (see [1] for further > information), but it is static.> $ grep BTRFS_MINOR -r include/ > include/linux/miscdevice.h:#define BTRFS_MINOR 234Ah - there it is! I''d only searched in fs/btrfs> I can conclude that _now_ the minor is 234 and not 55. But I don''t > know if it is a _stable_ interface.We''ll see ... now I know the error message and the place where I can examine the actual major and minor value. Should be enough information for the next months ... Thank you! Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Hullen wrote:> > If you do not use udev, you need to synchronise /dev/ > > node with /sys/class/misc/btrfs-control/dev manually on each boot. > > Solved (something like reverse engineering). > > I re-create the (permanent) entry /dev/btrfs-control using the > actual contents of "/sys/class/misc/btrfs-control/dev", and btrfs > is happy (and me too).This is fine, and is just what udev does; it creates the correct device node using kernel data. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Peter, Du meintest am 03.04.11:>> Solved (something like reverse engineering). >> >> I re-create the (permanent) entry /dev/btrfs-control using the >> actual contents of "/sys/class/misc/btrfs-control/dev", and btrfs >> is happy (and me too).> This is fine, and is just what udev does; it creates the correct > device node using kernel data.Maybe. But if I want a cup of milk I don''t buy a complete cow ... Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Hullen wrote:> >> Solved (something like reverse engineering). > >> > >> I re-create the (permanent) entry /dev/btrfs-control using the > >> actual contents of "/sys/class/misc/btrfs-control/dev", and btrfs > >> is happy (and me too). > > > This is fine, and is just what udev does; it creates the correct > > device node using kernel data. > > Maybe. But if I want a cup of milk I don''t buy a complete cow ...My point was that it''s not so much reverse engineering, it''s exactly how udev works, and that also makes it a really reliable solution. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Peter, Du meintest am 03.04.11:>>>> Solved (something like reverse engineering).[...]> My point was that it''s not so much reverse engineering, it''s exactly > how udev works, and that also makes it a really reliable solution.But in this special case Goffredo has shown that I neither need udev nor reverse engineering: the minor number is hard coded (but may have changed some time ago). Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html