DragonFly kernel List (threaded) for 2009-08
Re: VINUM should be operational w/ DEVFS now
as far as I can tell, finding a device by its serial number via
getsynthvnode should work already. It calls disklocate, which in turn
devfs_find_device_by_name first iterates the cdev_t list, and if
nothing is found by the given name, it iterates the alias list to
match the name. If an alias is found, then the cdev to which it points
So as long as make_dev_alias has already been called, one can call
getsynthvnode directly and it will work for serial numbers, as long as
"serno/" is prepended, as this is the alias' name.
To sum it up, prepending "serno/" to your call to getsynthvnode, if
you look for a serial number, should do the job.
2009/8/15 Matthew Dillon <email@example.com>:
> The vinum softraid driver should now be operational with devfs
> in the master repo. vinum should now be able to handle full 64 bit
> geometries (multi-terrabyte disk subsystems).
> In addition, vinum configurations may reference devices by serial
> number or devtab label. for example:
> drive drive0 device raid0.s1d
> drive drive1 device raid1.s1d
> drive drive2 device raid2.s1d
> drive drive3 device raid3.s1d
> volume myvol
> plex org raid5 128k
> sd drive drive0 length 50g
> sd drive drive1 length 50g
> sd drive drive2 length 50g
> sd drive drive3 length 50g
> And in /etc/devtab:
> raid0 serno WD-WCAVY0248702
> raid1 serno WD-WCAVY0250739
> raid2 serno WD-WCAVY0245831
> raid3 serno WD-WCAVY0246122
> The vinum configuration stored on-media stores translated values,
> so on-media the devices will be stored by serial number. e.g.
> vinum roots may or may not still be broken, only because we do not
> have a getsynthvnode() function which can find a drive by its serial
> Generally speaking, anyone using vinum will want to reference devices
> by serial number now to avoid renumbering problems.
> TASKS STILL TO DO (any takers?):
> * Add a feature to getsynthvnode() to locate a drive by its serial
> * Add general disk_create() support for vinum volumes. vinum
> historically insisted on being the partition manager for filesystems,
> but that isn't always convenient.
> * RAID-5 issues. vinum isn't smart about RAID-5. Have you every
> tried to rebuild parity on a 10TB vinum drive? We may need a
> SOC project to fix this... that is, sub-divide the space into
> smaller chunks and keep track of activity in the chunks so a rebuild
> does not have to rebuild the entire freaking topology.