DragonFly bugs List (threaded) for 2007-07
DragonFly BSD
DragonFly bugs List (threaded) for 2007-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

1.9.x slices, newfs, and vinum problem?


From: Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 08 Jul 2007 18:02:08 -0400

Hello,

My apologies for not testing earlier .. I'm trying to get my 'test lab'
up to speed in general, so unfortunately I haven't been following the
bleeding edge for all the features I'm using..

Am working on setting up a (physical) test machine running -HEAD as of
about a week ago. Don't think this is an issue as the relavent files
don't appear to have changed since my build.

I am able to create a simple vinum volume as follows:

  drive d1 device /dev/ad1s1a

  volume vk
    plex org concat
      sd length 6g drive d1

which passes the 'dd' i/o test
(as well as a more complicated striped volume on ad1s1a and ad3s1a)

but 'newfs -v /dev/vinum/vk' fails

  without -v : newfs: /dev/vinum/vk: unable to retrieve geometry
    information
  with -v : newfs: /dev/vinum/vk: is unavailable

dmesg snippet as follows:

vinum: loaded
vinum: CONFIGURATION OBLITERATED
ad1s1: type 0xa5, start 63, end = 78156287, size 78156225 : OK
vinum: drive d1 is up
ad3s1: type 0xa5, start 63, end = 78156287, size 78156225 : OK
vinum: drive d2 is up
vinum: vk.p0.s0 is up
vinum: vk.p0.s1 is up
vinum: vk.p0 is up
vinum: vk is up
vinumioctl: invalid ioctl from process 759 (newfs): 40886468

So it looks like the disklabel rework broke some assumptions somehow..

on a quick inspection :

  sbin/newfs/newfs.c was changed to use the DIOCGPART ioctl to determine
  the partition info, rather than an internal? getdisklabel() call

  but DIOCGPART is not implemented for vinum,  hitting the 'error' case
  in newfs (and explaining the dmesg), which then checks for -v. if no
  -v, newfs gives 'unable to recieve..', if -v, nfs uses the stat()
  information , assuming the target is a raw file (as newfs was updated
   to work with raw files, which is overall useful)

  essentially, my guess is that it looks like vinum needs to be
  reworked to support the or similar new DIOCGPART ioctl..

So.. I know vinum isn't used by everyone.. if this sounds like the
problem, I can try to take a crack at fixing it, but I doubt I can make
the release branch .. e.g ~1 week at the earliest, owing to my n00b-ness..

Thanks,
- Chris



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]