Sorry for the newbie sounding post (well, I *am a zfs newb), but I''ve googled for a couple hours now and have yet to find a clear or specific answer... The zfs documentation indicates that it is very easy to make storage pools, using commands such as: zpool create tank raidz c1t0d0 c2t0d0 c3t0d0 My question: Where/how in the heck does one get a list of which devices are valid targets? I''ve got 4 SATA drives in a hot-swap backplane hooked to my motherboard... where do I look or what command should I use to see what I should put after the "zpool create [poolname] raidz" bit? There are a ton of things listed under /dev -- no clue which ones are "real" and which are just there, if you get my drift. System details, if necessary: Mobo: KINO 690S1 System Drive: 2.5" IDE with OpenSolaris 2005.08 installed. SATA is SB600 (southbridge). Case w/ hotswap bays is Chenbro ES34690 (if I recall correctly). BIOS is set to "IDE->AHCI" currently (options are IDE, Legacy, RAID, AHCI, and IDE-> AHCI). Thanks, --Ben This message posted from opensolaris.org
On Jun 3, 2008, at 16:35, Benjamin Ellison wrote:> ''ve got 4 SATA drives in a hot-swap backplane hooked to my > motherboard... where do I look or what command should I use to > see what I should put after the "zpool create [poolname] raidz" bit?See if ''cfgadm'' gives you a good list. You''re about an hour behind me on the learning curve (building a Nexenta box here - ZFS found a problem disk that was causing troubles previously - sweet!). -Bill ----- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 bfccomputing.com Page: 603.442.1833 Blog: blog.bfccomputing.com VCard: bfccomputing.com/vcard/bill.vcf
On Tue, Jun 3, 2008 at 4:35 PM, Benjamin Ellison <ben_a_ellison at rl.gov> wrote:> My question: Where/how in the heck does one get a list of which devices are valid targets?Run "format" and it''ll list the devices that are available. If you hot-plug a drive, you may need to run "devfsadm -c disk" first, to make sure that entries in /dev are created for it. Will
Thanks for the reply (Will''s too - although I see it hasn''t posted to the thread). "format" gets me a list of just my system drive. "devfsadm -c disk" just spins for a second, but doesn''t change anything found under format. "cfgadm" shows the following: App_Id Type Receptacle Occupant Condition sata0/0 sata-port empty unconfigured ok sata0/1 sata-port empty unconfigured ok sata0/2 sata-port empty unconfigured ok sata0/3 sata-port empty unconfigured ok Which looks somewhat promising -- from my un-tutored interpretation of that, it seems to knows there should be 4 SATA devices attached. Still -- nothing shows anything like the "c0t1d0" or similar. I may open the case back up and see if hooking a drive or two directly to the sata ports on the mobo (vs. the hotswap backplane) makes any difference... Thanks, --Ben This message posted from opensolaris.org
Will Murnane wrote:> On Tue, Jun 3, 2008 at 4:35 PM, Benjamin Ellison <ben_a_ellison at rl.gov> wrote: >> My question: Where/how in the heck does one get a list of which devices are valid targets? > Run "format" and it''ll list the devices that are available. If you > hot-plug a drive, you may need to run "devfsadm -c disk" first, to > make sure that entries in /dev are created for it.Some time ago I logged an RFE for this very issue bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6605832 6605832 zpool could tell me what disks are available for use It''s still unassigned, unfortunately. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems blogs.sun.com/jmcp jmcp.homeunix.com/blog
On Jun 3, 2008, at 16:50, Benjamin Ellison wrote:> "cfgadm" shows the following: > App_Id Type Receptacle Occupant Condition > sata0/0 sata-port empty unconfigured ok > sata0/1 sata-port empty unconfigured ok > sata0/2 sata-port empty unconfigured ok > sata0/3 sata-port empty unconfigured okJust for the sake of comparison, mine looks like: flowerpt at borlaug:~$ cfgadm Ap_Id Type Receptacle Occupant Condition sata0/0::dsk/c1t0d0 disk connected configured ok sata0/1::dsk/c1t1d0 disk connected configured ok --snip--- -Bill ----- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 bfccomputing.com Page: 603.442.1833 Blog: blog.bfccomputing.com VCard: bfccomputing.com/vcard/bill.vcf
your "Type" "sata-port" will change to "disk" when you put a disk on it. like: 1 % cfgadm Ap_Id Type Receptacle Occupant Condition sata0/0::dsk/c2t0d0 disk connected configured ok sata0/1::dsk/c2t1d0 cd/dvd connected configured ok sata1/0 sata-port empty unconfigured ok sata1/1 sata-port empty unconfigured ok sata1/2::dsk/c0t2d0 disk connected configured ok sata1/3::dsk/c0t3d0 disk connected configured ok sata1/4::dsk/c0t4d0 disk connected configured ok sata1/5::dsk/c0t5d0 disk connected configured ok sata1/6::dsk/c0t6d0 disk connected configured ok sata1/7 sata-port empty unconfigured ok sata3/0 sata-port empty unconfigured ok sata3/1::dsk/c4t1d0 disk connected configured ok sata3/2::dsk/c4t2d0 disk connected configured ok sata3/3::dsk/c4t3d0 disk connected configured ok sata3/4::dsk/c4t4d0 disk connected configured ok sata3/5 disk connected unconfigured unknown sata3/6::dsk/c4t6d0 disk connected configured ok sata3/7 sata-port empty unconfigured ok so to make the above hot-plugable disk active I would type: cfgadm -c configure sata3/5 and it would get a c4t5d0 assignment and I could then be added to a pool and seen in format. in your case, attach a disk :-) also, make sure your bios is set to AHCI.
James C. McPherson wrote:> Will Murnane wrote: > >> On Tue, Jun 3, 2008 at 4:35 PM, Benjamin Ellison <ben_a_ellison at rl.gov> wrote: >> >>> My question: Where/how in the heck does one get a list of which devices are valid targets? >>> >> Run "format" and it''ll list the devices that are available. If you >> hot-plug a drive, you may need to run "devfsadm -c disk" first, to >> make sure that entries in /dev are created for it. >> > > Some time ago I logged an RFE for this very issue > > bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6605832 > > 6605832 zpool could tell me what disks are available for use > > > It''s still unassigned, unfortunately. >methinks this is a command which will be much more useful beyond the ZFS context. In fact, it seems that the caiman project already has the code written to do this... just not externalized. You might see if we could promote test_td.c into a useful sys-admin command. cvs.opensolaris.org/source/xref/caiman/snap_upgrade/usr/src/lib/libtd/test_td.c -- richard
Richard Elling wrote:> James C. McPherson wrote: >> Will Murnane wrote: >> >>> On Tue, Jun 3, 2008 at 4:35 PM, Benjamin Ellison <ben_a_ellison at rl.gov> wrote: >>> >>>> My question: Where/how in the heck does one get a list of which devices are valid targets? >>>> >>> Run "format" and it''ll list the devices that are available. If you >>> hot-plug a drive, you may need to run "devfsadm -c disk" first, to >>> make sure that entries in /dev are created for it. >>> >> Some time ago I logged an RFE for this very issue >> >> bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6605832 >> >> 6605832 zpool could tell me what disks are available for use >> >> >> It''s still unassigned, unfortunately. >> > > methinks this is a command which will be much more useful beyond > the ZFS context. In fact, it seems that the caiman project already has > the code written to do this... just not externalized. You might see if > we could promote test_td.c into a useful sys-admin command. > cvs.opensolaris.org/source/xref/caiman/snap_upgrade/usr/src/lib/libtd/test_td.cPutting into the zpool command would feel odd to me, but I agree that there may be a useful utility here. Dave
Richard Elling wrote:> James C. McPherson wrote: >> Will Murnane wrote: >> >>> On Tue, Jun 3, 2008 at 4:35 PM, Benjamin Ellison <ben_a_ellison at rl.gov> wrote: >>> >>>> My question: Where/how in the heck does one get a list of which devices are valid targets? >>>> >>> Run "format" and it''ll list the devices that are available. If you >>> hot-plug a drive, you may need to run "devfsadm -c disk" first, to >>> make sure that entries in /dev are created for it. >>> >> Some time ago I logged an RFE for this very issue >> >> bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6605832 >> >> 6605832 zpool could tell me what disks are available for use >> >> >> It''s still unassigned, unfortunately. >> > > methinks this is a command which will be much more useful beyond > the ZFS context. In fact, it seems that the caiman project already has > the code written to do this... just not externalized. You might see if > we could promote test_td.c into a useful sys-admin command. > cvs.opensolaris.org/source/xref/caiman/snap_upgrade/usr/src/lib/libtd/test_td.cYes, that would be a very handy command to have around as a general tool. Especially if it could say "slice X is used by (mountpoint/...)" as well. James -- Senior Kernel Software Engineer, Solaris Sun Microsystems blogs.sun.com/jmcp jmcp.homeunix.com/blog
On Tue, 3 Jun 2008, Dave Miner wrote:> > Putting into the zpool command would feel odd to me, but I agree that > there may be a useful utility here.There is value to putting this functionality in zpool for the same reason that it was useful to put ''iostat'' and other "duplicate" functionality in zpool. For example, zpool can skip disks which are already currently in use, or it can recommend whole disks (rather than partitions) if none of the logical disk partitions are currently in use. The zfs commands are currently at least an order of magnitude easier to comprehend and use than the legacy commands related to storage devices. It would be nice if the zfs commands will continue to simplify what is now quite obtuse. Bob =====================================Bob Friesenhahn bfriesen at simple.dallas.tx.us, simplesystems.org/users/bfriesen GraphicsMagick Maintainer, GraphicsMagick.org
I dropped logicsupply a note asking if they had any specifics on the backplane used in my case. My guess is that it just isn''t compatible with opensolaris -- I have disks in the bays, but they show up empty in the OS. If I connect one of the drives directly to the mobo it shows up fine. Chances are fairly good I''ll just attempt to remove the backplane, get some molex-to-sata power adapters, and directly cable the drives to the motherboard until such a time as the backplane is supported. I will also need to figure out a good non-ugly and non-permanent way to keep the nifty hot-swap bays from being removed accidentally. --Ben This message posted from opensolaris.org
Bob Friesenhahn wrote:> On Tue, 3 Jun 2008, Dave Miner wrote: > >> Putting into the zpool command would feel odd to me, but I agree that >> there may be a useful utility here. >> > > There is value to putting this functionality in zpool for the same > reason that it was useful to put ''iostat'' and other "duplicate" > functionality in zpool. For example, zpool can skip disks which are > already currently in use, or it can recommend whole disks (rather than > partitions) if none of the logical disk partitions are currently in > use. >Nit: zpool iostat provides a different point of view on I/O than iostat. iostat cannot do what zpool iostat does, so it is not really a case of duplicate functionality. VxVM has a similar tool, vxstat. Today, zpool uses libdiskmgt to determine if the devices are in use or have existing file systems. If found, it will fail, unless the -f (force) flag is used. I have done some work on making intelligent decisions about using devices. It is a non-trivial task for the general case. Consider that a X4500 has 281,474,976,710,655 possible permutations for RAID-0 using only a single slice per disk, it quickly becomes an exercise of compromise. At present, I''m adding this to RAIDoptmizer, but there I have the knowledge of the physical layout of the system(s), which is difficult to ascertain (guess) for the generic hardware case. It may be that in the long term we could add some sort of smarts to zpool, but I''m not (currently) optimistic.> The zfs commands are currently at least an order of magnitude easier > to comprehend and use than the legacy commands related to storage > devices. It would be nice if the zfs commands will continue to > simplify what is now quite obtuse. >No doubt. -- richard
I agree with that. format(1M) and cfgadm(1M) are, ah, not the most user-friendly tools. It would be really nice to have ''zpool disks'' go out and taste all the drives to see which ones are available. We already have most of the code to do it. ''zpool import'' already contains the taste-all-disks-and-slices logic, and ''zpool add'' already contains the logic to determine whether a device is in use. Looks like all we''re really missing is a call to printf()... Is there an RFE for this? If not, I''ll file one. I like the idea. Jeff On Wed, Jun 04, 2008 at 10:55:18AM -0500, Bob Friesenhahn wrote:> On Tue, 3 Jun 2008, Dave Miner wrote: > > > > Putting into the zpool command would feel odd to me, but I agree that > > there may be a useful utility here. > > There is value to putting this functionality in zpool for the same > reason that it was useful to put ''iostat'' and other "duplicate" > functionality in zpool. For example, zpool can skip disks which are > already currently in use, or it can recommend whole disks (rather than > partitions) if none of the logical disk partitions are currently in > use. > > The zfs commands are currently at least an order of magnitude easier > to comprehend and use than the legacy commands related to storage > devices. It would be nice if the zfs commands will continue to > simplify what is now quite obtuse. > > Bob > =====================================> Bob Friesenhahn > bfriesen at simple.dallas.tx.us, simplesystems.org/users/bfriesen > GraphicsMagick Maintainer, GraphicsMagick.org > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > mail.opensolaris.org/mailman/listinfo/zfs-discuss
Jeff Bonwick wrote:> I agree with that. format(1M) and cfgadm(1M) are, ah, not the most > user-friendly tools. It would be really nice to have ''zpool disks'' > go out and taste all the drives to see which ones are available. > > We already have most of the code to do it. ''zpool import'' already > contains the taste-all-disks-and-slices logic, and ''zpool add'' > already contains the logic to determine whether a device is in use. > Looks like all we''re really missing is a call to printf()... > > Is there an RFE for this? If not, I''ll file one. I like the idea. >No argument that it''s useful, but I also believe that making format or other tools friendlier is useful as well, since the problem here applies to file systems that are not ZFS, too. If I''m not using ZFS, it seems unlike that my conceptual model is to go use zpool to figure out what''s on my disks. So, sure, add something to zpool for that realm, but I think we should do something to format or another tool to address the non-ZFS case. Dave> Jeff > > On Wed, Jun 04, 2008 at 10:55:18AM -0500, Bob Friesenhahn wrote: >> On Tue, 3 Jun 2008, Dave Miner wrote: >>> Putting into the zpool command would feel odd to me, but I agree that >>> there may be a useful utility here. >> There is value to putting this functionality in zpool for the same >> reason that it was useful to put ''iostat'' and other "duplicate" >> functionality in zpool. For example, zpool can skip disks which are >> already currently in use, or it can recommend whole disks (rather than >> partitions) if none of the logical disk partitions are currently in >> use. >> >> The zfs commands are currently at least an order of magnitude easier >> to comprehend and use than the legacy commands related to storage >> devices. It would be nice if the zfs commands will continue to >> simplify what is now quite obtuse. >> >> Bob >> =====================================>> Bob Friesenhahn >> bfriesen at simple.dallas.tx.us, simplesystems.org/users/bfriesen >> GraphicsMagick Maintainer, GraphicsMagick.org >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Wed, 4 Jun 2008, Jeff Bonwick wrote:> I agree with that. format(1M) and cfgadm(1M) are, ah, not the most > user-friendly tools. It would be really nice to have ''zpool disks'' > go out and taste all the drives to see which ones are available. > > We already have most of the code to do it. ''zpool import'' already > contains the taste-all-disks-and-slices logic, and ''zpool add'' > already contains the logic to determine whether a device is in use. > Looks like all we''re really missing is a call to printf()...Make sure that the zpool devices command recommends the configurations preferred for zfs first and requires that the user add an extra option (e.g. -v) in order to discover less ideal device configurations. For example, ZFS prefers whole disks so if the disk contains partitions but none of them are used, then it can simply suggest the whole disk, but if some partitions are used it can list the unused partitions along with a warning that using partitions is a non-ideal configuration. If the devices are accessed via different paths/controllers, then that could be useful info for the user when selecting devices. I appreciate that Richard Elling would like to suggest the best combination out of 281,474,976,710,655 permutations, but at some point the choice is best left to the educated user. :-) The first challenge is to find the devices at all. Optimization is for later. Bob =====================================Bob Friesenhahn bfriesen at simple.dallas.tx.us, simplesystems.org/users/bfriesen GraphicsMagick Maintainer, GraphicsMagick.org
> Putting into the zpool command would feel odd to me, but I agree that > there may be a useful utility here.There MAY be a useful utility here? I know this isn''t your fight Dave, but this tipped me and I have to say something :) Can we agree that the format command lists the disks it can use because the format command is part of the user-facing disk storage software stack and listing what objects it can act upon is one of the most fundemental features of the user-facing tools of the stack?! It is for this reason alone that ZFS needs a similar feature. Because it makes sense. The other reason is to help people. Every time someone asks this question, all they get is "try format it might work?" Or "scroll through 200 lines of dmesg they might be there?" People have been asking for this basic feature for how long now? Years? Probably since ZFS was created? Every couple weeks or months someone pops up on IRC or a forum asking about it, and can you blame them? Every ZFS tutorial touts how easy it all is without ever mentioning how you get the disk names for the very first step. This has always seemed crazy to me, but I can see how people close to the problem would not see it. After all, you guys with with solaris every day, it is your job. I hope you can see though that such a feature would not feel odd. It would not be questionably useful. It is not really optional, in fact. It is a requirement for a product that lives outside the laboratory, and opensolaris is quickly moving that way.... This message posted from opensolaris.org
MC wrote:>> Putting into the zpool command would feel odd to me, but I agree that >> there may be a useful utility here. >> > > There MAY be a useful utility here? I know this isn''t your fight Dave, but this tipped me and I have to say something :) > > Can we agree that the format command lists the disks it can use because the format command is part of the user-facing disk storage software stack and listing what objects it can act upon is one of the most fundemental features of the user-facing tools of the stack?! It is for this reason alone that ZFS needs a similar feature. Because it makes sense. >I''d like to suggest a name: lsdisk and lspart to list the disks and also the disks/partitions that are available. (Or maybe lsdisk should just list the disks and partitions in an indented list? Listing the partitions is important. Listing the controllers might not hurt anything, either.) Linux has lspci[0], lsscsi, lsusb, lsof, and a number of other ls-tab-tab utilities out-of-the-box[1]. These utilities would be quite intuitive for folks who''ve learned Linux first, and would help people transition to Solaris quickly. When I first learned Solaris (some years ago now), it took me a surprisingly long time to get the device naming scheme and the partition numbering. The naming/numbering is quite intuitive (except for that part about c0t0d0s2 being the entire device[1]), but I would have felt that I understood it quicker if I''d seen a nice listing that matches the concept, and also had quick way to find out the name of that disk that I just plugged in. My friends who are new to Solaris seem to have the same problem out of the gate. -Luke [0] Including lspci and lsusb with Solaris would be a great idea -- prtconf and prtdiag are very useful, but lspci is very quick, clear, and concise. IIRC, lspci is included in Nexenta. I haven''t checked for these utilities on the new OpenSolaris yet, though, so maybe they''re there already. [1] Since Solaris 10 still uses /bin/sh as the root shell, I feel that I must explain that this is tab completion. In bash/zsh/tcsh, hitting tab twice searches the $PATH for ls* and displays the results.... I know that most-everyone on the list already knows this, but I can''t help my self! [ducks!] [2] If I''m giving someone a tour of Solaris administration, /dev/sda isn''t particularly different from /dev/dsk/c0t0d0. But if I open /dev/dsk/c0t0d0s2 with a partitioning tool, repartition, then build/mount a filesystem without Something Bad happening, then my spectators heads usually explode. After that, they don''t believe me when I tell them that they mostly understand what''s going on. Yes, ZFS and the EFI disklabels fix this when you have a system with a ZFS root and no UFS disks -- but UFS is still necessary in a lot of configuration, so this kind of system-quirk should be made obvious to Unix-literate people coming from non-Solaris backgrounds.
> I''d like to suggest a name: lsdisk and lspart to list the disks and also > the disks/partitions that are available. (Or maybe lsdisk should just > list the disks and partitions in an indented list? Listing the > partitions is important. Listing the controllers might not hurt > anything, either.)Hmmm... the current scheme seems to be "subject verb <object>". E.g. disk list or disk info c1t9d0 disk info -p c1* With partitions, I assume you mean slices. Partitions are outside of Solaris and managed by fdisk.> Linux has lspci[0], lsscsi, lsusb, lsof, and a number of other > ls-tab-tab utilities out-of-the-box[1]. These utilities would be quite > intuitive for folks who''ve learned Linux first, and would help people > transition to Solaris quickly.Do we really need to bend and warp everything to suit Linux switchers? (only half :-).> When I first learned Solaris (some years ago now), it took me a > surprisingly long time to get the device naming scheme and the partition > numbering. The naming/numbering is quite intuitive (except for that > part about c0t0d0s2 being the entire device[1]), but I would have felt > that I understood it quicker if I''d seen a nice listing that matches the > concept, and also had quick way to find out the name of that disk that I > just plugged in. My friends who are new to Solaris seem to have the > same problem out of the gate.I did not have this experience. I came from BSD where there were things like /dev/sd0d (which also exist on Solaris), but the Sun way was not too strange...> [0] Including lspci and lsusb with Solaris would be a great idea --Well, there is scanpci.> [1] Since Solaris 10 still uses /bin/sh as the root shell, I feel that I > must explain that this is tab completion. In bash/zsh/tcsh, hitting tab > twice searches the $PATH for ls* and displays the results.... I know > that most-everyone on the list already knows this, but I can''t help my > self! [ducks!]At the risk of outing myself as a hardcore nit picker, in tcsh it is Control-D, and only once, not twice. :-)> > [2] If I''m giving someone a tour of Solaris administration, /dev/sda > isn''t particularly different from /dev/dsk/c0t0d0. But if I open > /dev/dsk/c0t0d0s2 with a partitioning tool, repartition, then > build/mount a filesystem without Something Bad happening, then my > spectators heads usually explode. After that, they don''t believe me > when I tell them that they mostly understand what''s going on. Yes, ZFS > and the EFI disklabels fix this when you have a system with a ZFS root > and no UFS disks -- but UFS is still necessary in a lot of > configuration, so this kind of system-quirk should be made obvious to > Unix-literate people coming from non-Solaris backgrounds.Maybe it''s because I have a Solaris background, but I fail to see any quirk here... Best regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: bb-c.de Am Wiesenpfad 6, 53340 Meckenheim Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 45 Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt
Volker A. Brandt wrote:> Hmmm... the current scheme seems to be "subject verb <object>". > E.g. > > disk listThat would work fine for me! It would also be easy enough to put on a "rosetta stone" type reference card.>> [0] Including lspci and lsusb with Solaris would be a great idea -- >> > > Well, there is scanpci. >I''m embarrased to admit that scanpci hadn''t lodged in my long-term memory until now... But why is it in /usr/X11/bin/, and not in /usr/sbin/ like the other utilities that inventory the hardware?>> When I first learned Solaris (some years ago now), it took me a >> surprisingly long time to get the device naming scheme and the partition >> numbering. The naming/numbering is quite intuitive (except for that >> part about c0t0d0s2 being the entire device[1]), but I would have felt >> that I understood it quicker if I''d seen a nice listing that matches the >> concept, and also had quick way to find out the name of that disk that I >> just plugged in. My friends who are new to Solaris seem to have the >> same problem out of the gate. >> > > I did not have this experience. I came from BSD where there were > things like /dev/sd0d (which also exist on Solaris), but the Sun > way was not too strange... >/dev/c0t0d0 isn''t strange. Merely unfamiliar to a Linux switcher. There just wasn''t a way to confirm that one was reading this list correctly, at the time. And running format seemed like a dangerous kludge, since I didn''t want to /modify/ the disks at all.>> [2] If I''m giving someone a tour of Solaris administration, /dev/sda >> isn''t particularly different from /dev/dsk/c0t0d0. But if I open >> /dev/dsk/c0t0d0s2 with a partitioning tool, repartition, then >> build/mount a filesystem without Something Bad happening, then my >> spectators heads usually explode. After that, they don''t believe me >> when I tell them that they mostly understand what''s going on. Yes, ZFS >> and the EFI disklabels fix this when you have a system with a ZFS root >> and no UFS disks -- but UFS is still necessary in a lot of >> configuration, so this kind of system-quirk should be made obvious to >> Unix-literate people coming from non-Solaris backgrounds. >> > > Maybe it''s because I have a Solaris background, but I fail to see > any quirk here... >I can explain why a partition with a Solaris disklabel inside an MSDOS partition makes sense (my apologies for sloppy use of the terminology earlier), and I can explain why BSD uses a similar technique when running on a system where the boot-firmware only understands MSDOS style disklabels.... But, the s2 thing is f-ed up, conceptually speaking: 1. Calling s2 a slice makes it a subset of the device, not the whole device. But it''s the whole device. 2. The number s2 is arbitrary. If it were s0, then there would at least be the beginning of the list. If it were s3, it would be at the end of a 2-bit list, which could be explained historically. If it were s7, it would be at the end of the list. But, no, it''s s2. Why? 3. None of the grey-haired Solaris gurus that I''ve talked to have ever been able to explain why. 4. Can you use s2 when the disk-label is corrupted? If it''s the whole disk, maybe you can. If it''s an entry in the disklabel, maybe you can''t. I seem to remember that I can write to s2 in order to fix a borked label, but that makes no sense, and I don''t believe it. Maybe I''m loosing my mind. But, then again, my point is that the s2 thing makes me loose my mind. :-) Using c0t0d0 to refer to the whole device (which works in some cases, such as zpool create) makes a lot of sense. If it''s a slice, it really should be a slice. I just accept that the s2 thing is the way it is, and Solaris disk management isn''t difficult or mysterious... But, these kind of quirks really did derail my learning process, and I''ve seen it derail the learning process of others, too. I realize that changing a fundamental part of the system for the sake of aesthetics would cause a lot of chaos for little benefit... So I''m just suggesting that the normal disk tools be changed to make this quirk obvious at a glance -- so that the uninitiated may learn the system more easily. -Luke
Luke Scharf wrote:> 3. None of the grey-haired Solaris gurus that I''ve talked to have > ever been able to explain why. >I do realize that older architectures needed some way to record the disk geometry. But why do it that way? -Luke
Luke Scharf wrote:> 1. Calling s2 a slice makes it a subset of the device, not the whole > device. But it''s the whole device. > 2. The number s2 is arbitrary. If it were s0, then there would at > least be the beginning of the list. If it were s3, it would be at > the end of a 2-bit list, which could be explained historically. > If it were s7, it would be at the end of the list. But, no, it''s > s2. Why? > 3. None of the grey-haired Solaris gurus that I''ve talked to have > ever been able to explain why. > 4. Can you use s2 when the disk-label is corrupted? If it''s the > whole disk, maybe you can. If it''s an entry in the disklabel, > maybe you can''t. I seem to remember that I can write to s2 in > order to fix a borked label, but that makes no sense, and I don''t > believe it. Maybe I''m loosing my mind. But, then again, my point > is that the s2 thing makes me loose my mind. :-)Slice 2 is historically the "whole disk" slice (since long before Solaris). The extra encapsulation layer on x86 hardware caused by ancient crappy BIOSes is unfortunate. And s2 isn''t special in any way except convention. _Any_ slice that starts at sector 0 (and ends far enough away) will behave the same. If your disk label is broken/missing/whatever, you won''t _have_ an s2. On x86en, you should probably use p0 for whole-disk operations... -- Carson
On Wed, Jun 04, 2008 at 06:28:58PM -0400, Luke Scharf wrote:> 2. The number s2 is arbitrary. If it were s0, then there would at > least be the beginning of the list. If it were s3, it would be at > the end of a 2-bit list, which could be explained historically. > If it were s7, it would be at the end of the list. But, no, it''s > s2. Why? > 3. None of the grey-haired Solaris gurus that I''ve talked to have > ever been able to explain why.This appears to be convention on (some?) BSDs from before Solaris existed. Best story I''ve heard is that it dates from before the time when modifiable (or at least *easily* modifiable) slices didn''t exist. No hopping into ''format'' or using ''fmthard''. Instead, your disk came with an entry in ''format.dat'' with several fixed slices. To give some flexibility, certain slices were arranged around common use cases. a and b consumed an "early" part of the disk, in a pattern often usable as "root" and "swap". c consumed everything, so you could use that for the whole disk instead. d,e,f,g consumed the "later" part of the disk for /var,/usr,etc. h consumed the exact area that f and g did. So you could use the entire disk with any of: a,b,d,e,f,g a,b,d,e,h c without having to change the label. I speculate that then utilities were written that used c/2 for information about the entire disk and people thought keeping the convention going was good.> 4. Can you use s2 when the disk-label is corrupted?You can''t use any slices when the disk label is corrupted. The ''sd'' driver won''t allow you access to them unless it''s happy with the label. Trying with ''dd'' will give you an I/O error.> If it''s the > whole disk, maybe you can. If it''s an entry in the disklabel, > maybe you can''t. I seem to remember that I can write to s2 in > order to fix a borked label, but that makes no sense, and I don''t > believe it. Maybe I''m loosing my mind. But, then again, my point > is that the s2 thing makes me loose my mind. :-)s2 is special only by convention, not by code. The sd driver can create a label without a label existing (and therefore without any slices present). You can later use access to block 0 (via any slice) to corrupt (...er *modify*) that label, but that''s not a feature of s2. s0 would do it as well with the way most disks are labled (because it also contains cylinder 0/block 0.)> Using c0t0d0 to refer to the whole device (which works in some cases, > such as zpool create) makes a lot of sense. If it''s a slice, it really > should be a slice.Historically that wasn''t done, and it only works today if the application is handling it specifically or if you have an EFI label. -- Darren
On Wed, 2008-06-04 at 23:12 +0000, A Darren Dunham wrote:> Best story I''ve heard is that it dates from before the time when > modifiable (or at least *easily* modifiable) slices didn''t exist. No > hopping into ''format'' or using ''fmthard''. Instead, your disk came with > an entry in ''format.dat'' with several fixed slices.format.dat? bah. in some systems I used - notably 4.2/4.3BSD on the vax and some even more obscure hardware - the partition table was *compiled into the device driver* (one table per known disk type). Don''t like the partition layout? you have kernel source, you can change it... Disk labels didn''t turn up until after BSD4.3.> So you could use the entire disk with any of: > a,b,d,e,f,g > a,b,d,e,h > cRight. You''d typically use the a/b/d/e/f/g or a/b/d/e/h slice on your boot disk and the c slice on additional disks.> without having to change the label.And the reason why changing the label was avoided was because it required recompiling the kernel and rebooting.> I speculate that then utilities were written that used c/2 for > information about the entire disk and people thought keeping the > convention going was good.it''s more like it was too painful to change.> You can later use access to block 0 (via any slice) to corrupt (...er > *modify*) that label, but that''s not a feature of s2. s0 would do it as > well with the way most disks are labled (because it also contains > cylinder 0/block 0.)and why didn''t this get fixed? inertia. because slices are implemented in the disk driver by looking at the low order bits of the disk minor number, you couldn''t just wedge in an additional device instance for the unsliced disk without taking away one slice or re-creating *all* of your disk block & character devices. - Bill
Carson Gaspar wrote:> And s2 isn''t special in any way except convention. _Any_ slice that > starts at sector 0 (and ends far enough away) will behave the same. If > your disk label is broken/missing/whatever, you won''t _have_ an s2. >So, can I build a working system without s2? I think the last time I tried was a Sparc 5 about 7 years ago, and it didn''t really work. But maybe it would work on x86... Ever since I figured out what was going on, I''ve been mindful not to bust the convention. -Luke
On Thu, Jun 05, 2008 at 11:13:01AM -0400, Luke Scharf wrote:> So, can I build a working system without s2?Build? I''m not so sure. The first label is going to have s2 by default. You''d have to remove it later. I doubt there''s language in the jumpstart scripts to remove it then. But yes, removing it later should have little effect. I know older VxVM utilities absolutely required it (they would not add a disk without a valid s2 present). But otherwise, I can''t think of much that is likely to break. Some of the SDS utilities that configured metasets even created and applied labels with an empty s2. Anything that does have a problem may not be able to deal with EFI labels as well... -- Darren
I agree 100%. If we went by "this is how we always did it," then we would not have ZFS :) Charles (not to mention X64, CMT, or iPhones!;) On 6/4/08 10:55 AM, "Bob Friesenhahn" <bfriesen at simple.dallas.tx.us> wrote:> On Tue, 3 Jun 2008, Dave Miner wrote: >> >> Putting into the zpool command would feel odd to me, but I agree that >> there may be a useful utility here. > > There is value to putting this functionality in zpool for the same > reason that it was useful to put ''iostat'' and other "duplicate" > functionality in zpool. For example, zpool can skip disks which are > already currently in use, or it can recommend whole disks (rather than > partitions) if none of the logical disk partitions are currently in > use. > > The zfs commands are currently at least an order of magnitude easier > to comprehend and use than the legacy commands related to storage > devices. It would be nice if the zfs commands will continue to > simplify what is now quite obtuse. > > Bob > =====================================> Bob Friesenhahn > bfriesen at simple.dallas.tx.us, simplesystems.org/users/bfriesen > GraphicsMagick Maintainer, GraphicsMagick.org----- Charles Soto charles.soto at austin.utexas.edu Director, Information Technology? ? ? ?? TEL: 512-740-1888 The University of Texas at Austin?? ?? ? FAX: 512-475-9711 College of Communication, CMA 5.150G 1 University Station A0900, Austin, TX 78712 communication.utexas.edu/technology
Aaargh! My perfect case not working!! The back-pane should not be just a "pass-trough"? There was something unmounted? The power was not enough for all the disks? Can it depend on the disks? Did you have some replies? I would tell also to tech support of Chenbro directly (chenbro.com/corporatesite/service_support.php), this is the best case I''ve seen for a small factor high-end home fileserver! This message posted from opensolaris.org