From owner-freebsd-hackers Mon Sep 18 18:32:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id 776AE37B422; Mon, 18 Sep 2000 18:32:19 -0700 (PDT) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id FAA01937; Tue, 19 Sep 2000 05:32:10 +0400 (MSD) Message-Id: <200009190132.FAA01937@aaz.links.ru> Subject: Re: device naming convention In-Reply-To: <39C63C03.2C4C26F8@newsguy.com> from "Daniel C. Sobral" at "Sep 19, 0 01:00:03 am" To: dcs@newsguy.com (Daniel C. Sobral) Date: Tue, 19 Sep 2000 05:32:09 +0400 (MSD) Cc: intmktg@CAM.ORG, babolo@links.ru, freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG From: "Aleksandr A.Babaylov" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel C. Sobral writes: > Marc Tardif wrote: > > > > 4. If I want to use /dev/wd0s2 as a raw slice for reading > > > > and writing, what are the steps to follow? > > > You can't write several blocks near /dev/wd0s2 beginning. > > > Use /dev/wd0 with proper address > > > > > That is rather risky. Wouldn't it be safer to have a device name I could > > dedicate to some purpose. In such a case, I could chown the device to an > > appropriate username and group. Furthermore, I could avoid the unfortunate > > mistake of overwriting my current FreeBSD fs in case I get the addresses > > wrong. > He is incorrect. You can use /dev/wd0s2 any way you want, as long as you > have nothing of value there. It is English that I know bad. Labeling, partitioning so on I know MUCH better. So I take a time and dictionary and because of long letter I begin with conclusion. There is risky use any partition or slice with FreeBSD for arbitrary purposes. May be any file system except ffs can work improperly (msdos, ntfs, hpfs, 9660) Things are worst - ffs does not stable too, but this is far from subject of this letter. OK, lets verify. "cicuta/home/babolo(N)#" is prompt, number before is exit code. Look at test disk: 0cicuta/home/babolo(1)#fdisk wd0 ******* Working on device /dev/rwd0 ******* parameters extracted from in-core disklabel are: cylinders=1011 heads=15 sectors/track=44 (660 blks/cyl) parameters to be used for BIOS calculations are: cylinders=1011 heads=15 sectors/track=44 (660 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 50160 (24 Meg), flag 0 beg: cyl 0/ sector 1/ head 0; end: cyl 75/ sector 44/ head 14 The data for partition 2 is: sysid 0,(unused) start 50160, size 50160 (24 Meg), flag 0 beg: cyl 76/ sector 1/ head 0; end: cyl 151/ sector 44/ head 14 The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 100320, size 50160 (24 Meg), flag 0 beg: cyl 152/ sector 1/ head 0; end: cyl 227/ sector 44/ head 14 The data for partition 4 is: sysid 0,(unused) start 0, size 0 (0 Meg), flag 80 (active) beg: cyl 0/ sector 0/ head 0; end: cyl 0/ sector 0/ head 0 Now read slices: 0cicuta/home/babolo(2)#dd if=/dev/wd0s1 of=/dev/null bs=660b 76+0 records in 76+0 records out 25681920 bytes transferred in 17.175867 secs (1495233 bytes/sec) 0cicuta/home/babolo(3)#dd if=/dev/wd0s2 of=/dev/null bs=660b 1+1 records in 1+1 records out 368640 bytes transferred in 0.258831 secs (1424250 bytes/sec) 0cicuta/home/babolo(4)#dd if=/dev/wd0s3 of=/dev/null bs=660b 76+0 records in 76+0 records out 25681920 bytes transferred in 22.601690 secs (1136283 bytes/sec) 0cicuta/home/babolo(5)#dd if=/dev/wd0s4 of=/dev/null bs=660b 0+0 records in 0+0 records out 0 bytes transferred in 0.000036 secs (0 bytes/sec) 3 equal slices, test if wd0s2 has some error in it: 0cicuta/home/babolo(6)#dd if=/dev/wd0 of=/dev/null bs=660b 1011+0 records in 1011+0 records out 341637120 bytes transferred in 283.316634 secs (1205849 bytes/sec) Whole disk read successfully. What the test system is? 0cicuta/home/babolo(7)#uname -a FreeBSD cicuta.babolo.ru 2.2.7-RELEASE FreeBSD 2.2.7-RELEASE #0: Tue Dec 29 04:10:35 MSK 1998 babolo@cicuta.babolo.ru:/usr/src/sys/compile/cicuta i386 0cicuta/home/babolo(8)#dmesg [skip] wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , 32-bit, multi-block-8 wd0: 325MB (667260 sectors), 1011 cyls, 15 heads, 44 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, accel, dma, iordis wcd0: 171/1367Kb/sec, 128Kb cache, audio play, 255 volume levels, ejectable tray wcd0: no disc inside, unlocked, lock protected [skip] wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) The end of dmesg give the idea, why can't read whole wd0s2 slice. Now about white protected area in slice that is NOT marked 165 (FreeBSD): 0cicuta/home/babolo(9)#dd of=/dev/wd0s2 if=/dev/zero bs=660b dd: /dev/wd0s2: Invalid argument 3+0 records in 2+0 records out 675840 bytes transferred in 0.224398 secs (3011793 bytes/sec) 1cicuta/home/babolo(11)#od -b /dev/wd0s2 0000000 353 020 220 220 121 120 006 123 122 350 300 000 132 133 007 131 0000020 131 313 374 061 311 216 301 216 331 216 321 274 000 174 211 346 0000040 277 000 007 376 305 363 245 276 356 175 200 372 200 162 054 266 0000060 001 350 147 000 271 001 000 276 276 215 266 001 200 174 004 245 0000100 165 007 343 031 366 004 200 165 024 203 306 020 376 306 200 376 0000120 005 162 351 111 343 341 276 114 175 353 122 061 322 211 026 000 [skiped] 0017060 070 066 040 102 117 117 124 012 104 145 146 141 165 154 164 072 0017100 040 045 165 072 045 163 050 045 165 054 045 143 051 045 163 012 0017120 142 157 157 164 072 040 000 116 157 040 045 163 012 000 146 157 0017140 162 155 141 164 000 111 156 166 141 154 151 144 040 045 163 012 0017160 000 171 145 163 000 156 157 000 113 145 171 142 157 141 162 144 0017200 072 040 045 163 012 000 045 163 040 000 116 157 164 040 165 146 0017220 163 012 000 163 154 151 143 145 000 154 141 142 145 154 000 160 0017240 141 162 164 151 164 151 157 156 000 060 061 062 063 064 065 066 0017260 067 070 071 141 142 143 144 145 146 045 143 010 000 104 151 163 0017300 153 040 145 162 162 157 162 040 060 170 045 170 040 050 154 142 0017320 141 075 060 170 045 170 051 012 000 000 000 000 001 000 000 000 0017340 057 174 134 055 000 000 000 000 000 000 000 000 000 000 000 000 0017360 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 * 1320000 Why I use 2.2.7 for test? Because of my lovely 4.1-STABLE is extremly unstable with content of ad0s2 (wd0s2) above and silently reboot after the first dd in the test above. What is slices content? s1 - almost right FreeBSD label s2 - not a right FreeBSD label but similar enough to label. s3 - no label or similar at all. How to do such a content that screw the system? This is my way for this test: - shorten s2 to 3 cilinder. - disklabel -w -r wd0s2 fd360 - restore s2 size. How can you guarantee that occasionally some bits in slice do not fraud FreeBSD if used for arbitrary bits? Do not use slice begin at all. Does 4.1 behave similar? Yes, I know that. But it take some time to select bites in slice begin in such a way that 4.1 not reboot so friquently. You have idea and can test yourself. Remember - 4.1 is HIGHLY unstable during pseudolabel tests. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message