Date: Wed, 06 Mar 2002 15:19:42 -0600 From: Craig Boston <craig@meoqu.gank.org> To: stable@freebsd.org Cc: sos@freebsd.dk, grog@freebsd.org Subject: Vinum on ATA-RAID devices (was Re: Request for testers of new ATA driver patches) Message-ID: <3C8687EE.9060304@meoqu.gank.org> References: <200203060821.g268LR045942@freebsd.dk> <3C864253.5000700@meoqu.gank.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------060502070207080500010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Craig Boston wrote: > (blah blah blah) Okay, this is the last post to the list on this topic. I promise :) It appears my previous patch is not quite enough. It gets vinum working all right, but every time I reboot it "forgets" the config and has to be re-created. I tracked the problem down to the fact that ar devices aren't in the list provided by getdevs(), and that's how vinum figures out where to load its configuration from. So, the attached patch should fix both problems. I've been running it for the past few hours (along with the backported -current ATA driver), and so far everything is working flawlessly and has survived a couple buildworlds while my mirror is rebuilding. vinum ld shows: D alpha State: up Device /dev/ar0s1e Avail: 1/18600 MB (0%) D beta State: up Device /dev/ar1s1e Avail: 1/18600 MB (0%) Yay! :) The more I think about it, the more I see the usefulness of vinum on ar devices. For example, if your RAID controller lets you create new arrays but not expand existing ones, you could add it to a vinum span set to simulate the effect (I've had to do this with Compaq SCSI RAIDs). Søren: It's your driver -- is there any particular reason that ar should be left off the devstat list? My patch adds a devstat entry for it, but never removes it. As far as I can tell disk_destroy never happens for ata-raid devices, so I think/hope this is the correct behaviour. It also doesn't implement devstat transactions, but I'm not sure if that even makes sense due to ar being more of an abstraction. I don't know yet if there will be any ill effects from doing this as I'm not incredibly familiar with the ATA subsystem. The patch is for -stable systems with Soren's -current ATA driver backport already applied. I also have a version for stock RELENG_4 systems with the old driver, but am not posting it because it can cause problems due to vinum being able to access the subdisks directly and it reading them first. I doubt the patch will apply cleanly to -current, but with a few minor changes should be able to work... Thanks -- I'll stop bugging you guys now :) Craig --------------060502070207080500010403 Content-Type: application/gzip; name="ar-vinum-2002-0306.patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ar-vinum-2002-0306.patch.gz" H4sICKN2hjwAA2FyLXZpbnVtLTIwMDItMDMwNi5wYXRjaACNU21v2jAQ/hx+xakfJgrJSMKr gphgg07RtFGFaFP3xTKxU7LmBTkJXaftv+/sICCspYuUs32+5/HdPbZhGJA/5R3Gdx1aUPkb gkbs7Ub7xhl8pgJgAFbPMbtO3wLbNO1Gu93+H0zX6Q0d064w0ykYQ1MfQBvtEKbTBsgvSgtN 07IwzHkx1rROC6o5hCJLIC+oKNADLMofoNWpMCVB1KBHEBlnwQNRUWOJPcRLP2ZCBacQZgIE X5dRzF6k4ClTBDi+Am9LeF6IMigA68cTC02avMp+70KiQjwdjqviNU2VIY06TE5iuuZxJ4+j gGNUGYYHDDLJ9HA4MMugbUzRbrKYcaFi/4wbxksaBmd6WCPH7L+i4TnGthxzeNTQGo2kiHKw LCWjJrMNsrSI0pKPVfLopIKgL4zuSbCh6T1nTcG2OpjX40Zb23eJUMaI6lTzDe4a71Qjdbii 4koH5YnLVIf54it5v3K/L3TEarha+TOffFmSpTdfeIs58WcfV7U9/+52Qeaut/jgw2+oed0b 4s7rTLeeu/Rc/w4Rq08ywX0NmCZMlEwkwKtQ8OYxpyphuYdF4VLWK8t61HFaQdQS6RQRFhcR JnYWMiL01BtlefSLk4T+xD27P4DWseK6uDtscVLZKKsrZY6cbvdZdS+Dej3H7p08UaUu2lGl LRIk9Ac+gQlY1qBSF3icc4hCaK6DZNtkKU04ivbIUDT7GiYTVBkftYzEe4vNPj7fU77uvtHP s6kr8C/bzJ+BN3Pn6inWsusPL2bH6AnfWWHdi8hdeor8C2JUEOIwBQAA --------------060502070207080500010403-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8687EE.9060304>