Re: mSATA strangeness (was Re: gpart strangeness)
Never mind, I found the issue hw.ata.ata_dma=0 hw.ata.atapi_dma=0 in /boot/loader.conf, hanging around from the days of wood burning power supplies was causing this strange behaviour! Sorry for the noise folks! ---Mike On 8/22/2018 12:17 PM, Mike Tancsa wrote: > OK, > Some more odd things going on. If I write to a file from dd some random > junk, not all of the file is saved when I do an unmount. This seems to > be specific either to the ata controller of the APU or to the msata disk > as I tested on a regular server with plain old disks and no issue > > Eric, any chance you can try this on your APU as well ? > > > 0# umount /mnt > 0# mount /dev/ada0p1 /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.101394 secs (20683253 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = acca1d8997c3b9d906b40d99cba734b6 > 0# hd /mnt/junk2 > /tmp/hd-junk2 > 0# ls -l /mnt/junk2 > -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 > 0# umount /mnt > 0# mount /dev/ada0p1 /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 2ef0cadf32db4e07a8edf4fc66f8a4eb > 0# ls -l /mnt/junk2 > -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 > 0# hd /mnt/junk2 > /tmp/hd-junk2-post-mount > 0# ls -l /tmp/hd-junk2* > -rw--- 1 root wheel - 10354697 Aug 22 11:54 /tmp/hd-junk2 > -rw--- 1 root wheel - 1941594 Aug 22 11:54 /tmp/hd-junk2-post-mount > 0# > > If I do the same test on a USB stick it works as expected > > 0# umount /mnt > 0# mount /dev/da0p1 /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.102256 secs (20508777 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 > 0# umount /mnt > 0# mount /dev/da0p1 /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 > 0# > Same with an SD card. All is OK > > 0# umount /mnt > 0# mount /dev/mmcsd0s2a /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.107400 secs (19526588 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 > 0# umount /mnt > 0# mount /dev/mmcsd0s2a /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 > 0# > > Looking at hd before and after, its missing the end of the file > > --- hd-junk22018-08-22 11:54:09.891572000 -0400 > +++ hd-junk2-post-mount 2018-08-22 11:54:41.996983000 -0400 > @@ -24574,106500 +24574,6 @@ > 0005ffd0 8b 71 87 b8 78 03 72 ca 0e 06 3b d4 31 fd 18 f8 > |.q..x.r...;.1...| > 0005ffe0 de 39 72 fb c8 39 fd 1f 93 75 10 de 05 56 43 fb > |.9r..9...u...VC.| > 0005fff0 40 ce 54 e2 a4 17 3e 1e ec 01 b7 fd 1b 69 b7 6f > |@.T...>..i.o| > -0006 91 f3 02 ea 95 f4 12 1c bf 00 68 1b 3d 8c 01 43 > |..h.=..C| > -00060010 f6 5b 4e ec 7f 37 19 15 5b c4 e6 fb 88 27 1c 54 > |.[N..7..['.T| > -00060020 15 6c 02 7d fb 00 06 c1 4a 4a bf ce 9a 1b fe d4 > |.l.}JJ..| > -00060030 1c 3c b5 05 b6 4f 4e 62 b5 03 e3 e7 5e 27 d6 71 > |.<...ONb^'.q| > -00060040 ea 22 00 99 9d 13 e8 a9 64 0e fd 13 cc 23 73 67 > |."..d#sg| > -00060050 8e 78 0a ad ae 70 ab e4 22 b4 b7 b9 3b 75 9f 85 > |.x...p.."...;u..| > -00060060 53 39 0c af 15 39 5f 04 ac 3c 65 e9 ea 29 1d b7 > |S9...9_.. -00060070 ea f0 2f 19 3c 6d 1c 21 f1 58 4a 4b a8 26 8e f6 > |../. -00060080 05 99 8a 9d 54 75 e4 77 78 78 6c 75 21 31 d4 0c > |Tu.wxxlu!1..| > -00060090 52 88 c6 65 c0 09 04 ce 7f 5f 29 0c 46 9a 68 13 > |R..e._).F.h.| > -000600a0 73 30 97 78 d7 b7 d2 ba 8f 73 27 58 3d eb 0c d6 > |s0.x.s'X=...| > > > 1# camcontrol identify ada0 > pass0: ACS-3 ATA SATA 3.x device > pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) > > protocol ATA/ATAPI-10 SATA 3.x > device model SATA SSD > firmware revision S9FM02.0 > serial number 81B5074C1B6500076878 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 31277232 sectors > LBA48 supported 31277232 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > Zoned-Device Commands no > > Feature Support Enabled Value Vendor > read ahead yes yes > write cacheyes yes > flush cacheyes yes > overlapno > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > NCQ Queue Management no > NCQ Streaming no > Receive & Send FPDMA Queuedno > SMART yes yes > microcode download yes yes > security yes no > power management
Re: gpart strangeness (solved)
On 8/21/2018 2:30 PM, Mike Tancsa wrote: > On 8/21/2018 9:51 AM, Eugene Grosbein wrote: >> >> It seems like faulty media to me: it silently returns bad data. OK, it was a config issue on my part! Some legacy config from the long ago days of Soekris 5501s, had hw.ata.ata_dma=0 hw.ata.atapi_dma=0 in /boot/loader.conf Commenting those out fixed the issue! Sorry for the noise everyone! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
mSATA strangeness (was Re: gpart strangeness)
OK, Some more odd things going on. If I write to a file from dd some random junk, not all of the file is saved when I do an unmount. This seems to be specific either to the ata controller of the APU or to the msata disk as I tested on a regular server with plain old disks and no issue Eric, any chance you can try this on your APU as well ? 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.101394 secs (20683253 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = acca1d8997c3b9d906b40d99cba734b6 0# hd /mnt/junk2 > /tmp/hd-junk2 0# ls -l /mnt/junk2 -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 2ef0cadf32db4e07a8edf4fc66f8a4eb 0# ls -l /mnt/junk2 -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 0# hd /mnt/junk2 > /tmp/hd-junk2-post-mount 0# ls -l /tmp/hd-junk2* -rw--- 1 root wheel - 10354697 Aug 22 11:54 /tmp/hd-junk2 -rw--- 1 root wheel - 1941594 Aug 22 11:54 /tmp/hd-junk2-post-mount 0# If I do the same test on a USB stick it works as expected 0# umount /mnt 0# mount /dev/da0p1 /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.102256 secs (20508777 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 0# umount /mnt 0# mount /dev/da0p1 /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 0# Same with an SD card. All is OK 0# umount /mnt 0# mount /dev/mmcsd0s2a /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.107400 secs (19526588 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 0# umount /mnt 0# mount /dev/mmcsd0s2a /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 0# Looking at hd before and after, its missing the end of the file --- hd-junk22018-08-22 11:54:09.891572000 -0400 +++ hd-junk2-post-mount 2018-08-22 11:54:41.996983000 -0400 @@ -24574,106500 +24574,6 @@ 0005ffd0 8b 71 87 b8 78 03 72 ca 0e 06 3b d4 31 fd 18 f8 |.q..x.r...;.1...| 0005ffe0 de 39 72 fb c8 39 fd 1f 93 75 10 de 05 56 43 fb |.9r..9...u...VC.| 0005fff0 40 ce 54 e2 a4 17 3e 1e ec 01 b7 fd 1b 69 b7 6f |@.T...>..i.o| -0006 91 f3 02 ea 95 f4 12 1c bf 00 68 1b 3d 8c 01 43 |..h.=..C| -00060010 f6 5b 4e ec 7f 37 19 15 5b c4 e6 fb 88 27 1c 54 |.[N..7..['.T| -00060020 15 6c 02 7d fb 00 06 c1 4a 4a bf ce 9a 1b fe d4 |.l.}JJ..| -00060030 1c 3c b5 05 b6 4f 4e 62 b5 03 e3 e7 5e 27 d6 71 |.<...ONb^'.q| -00060040 ea 22 00 99 9d 13 e8 a9 64 0e fd 13 cc 23 73 67 |."..d#sg| -00060050 8e 78 0a ad ae 70 ab e4 22 b4 b7 b9 3b 75 9f 85 |.x...p.."...;u..| -00060060 53 39 0c af 15 39 5f 04 ac 3c 65 e9 ea 29 1d b7 |S9...9_.. ACS-3 ATA SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) protocol ATA/ATAPI-10 SATA 3.x device model SATA SSD firmware revision S9FM02.0 serial number 81B5074C1B6500076878 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 31277232 sectors LBA48 supported 31277232 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queuedno SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management no no media status notification no no power-up in Standbyno no write-read-verify no no unload yes yes general purpose loggingyes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 31277232/31277232 HPA - Security no 0# On 8/21/2018 2:30 PM, Mike Tancsa wrote: > On 8/21/2018 9:51 AM, Eugene Grosbein wrote: >> >> It seems like faulty media to me: it silently returns bad data. >> >> There is an easy way to verify this just with naked eye: >> >> yes | dd bs=128k of=/dev/ada0 >> hd
Re: gpart strangeness
On 8/21/18 1:30 PM, Mike Tancsa wrote: There are 3 of these disks I found. Unfortunately, they all seem a little different from the revision stamps on the board. They are all from PCEngines who generally seem to source quality products. This is in an APU3 I have an APU2. My disk is exactly like your 'good' disk, except for the serial number, obviously. I don't have any trouble. Maybe you can update the firmware on your bad disk. I have no idea how. Eric ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gpart strangeness
On 8/21/2018 9:51 AM, Eugene Grosbein wrote: > > It seems like faulty media to me: it silently returns bad data. > > There is an easy way to verify this just with naked eye: > > yes | dd bs=128k of=/dev/ada0 > hd /dev/ada0 > > That is, hd(1) should write back only 3 lines of output: > > 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| > * > 0100 > > If not, the media if faulty. > There are 3 of these disks I found. Unfortunately, they all seem a little different from the revision stamps on the board. They are all from PCEngines who generally seem to source quality products. This is in an APU3 A "bad" disk 0# camcontrol identify ada0 pass0: ACS-3 ATA SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) protocol ATA/ATAPI-10 SATA 3.x device model SATA SSD firmware revision S9FM02.0 serial number DED9075313EC01677930 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 31277232 sectors LBA48 supported 31277232 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queuedno SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management no no media status notification no no power-up in Standbyno no write-read-verify no no unload yes yes general purpose loggingyes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 31277232/31277232 HPA - Security no 0# vs a 'good' disk # camcontrol identify ada0 pass0: ACS-4 ATA SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) protocol ATA/ATAPI-11 SATA 3.x device model SATA SSD firmware revision SBFM01.0 serial number A44907781CE300040613 WWN 5000 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 31277232 sectors LBA48 supported 31277232 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queuedno SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standbyno no write-read-verify no no unload no no general purpose loggingyes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 31277232/31277232 HPA - Security no % diff good bad 1c1 < pass0: ACS-4 ATA SATA 3.x device --- > pass0: ACS-3 ATA SATA 3.x device 4c4 < protocol ATA/ATAPI-11 SATA 3.x --- > protocol ATA/ATAPI-10 SATA 3.x 6,8c6,7 < firmware revision SBFM01.0 < serial number A44907781CE300040613 < WWN 5000 --- > firmware revision S9FM02.0 > serial number DED9075313EC01677930 34c33 < advanced power management no no --- > advanced power management yes no 0/0x00 39c38 < unload no no --- > unload yes yes 46a46 > 1# yes | dd bs=128k of=/dev/ada0 dd: /dev/ada0: short write on
Re: gpart strangeness
21.08.2018 20:20, Mike Tancsa wrote: > On 8/20/2018 11:34 PM, Eugene Grosbein wrote: >>> I was trying to create a single partition on a 16G mSata drive and >>> whenever I add a partition, all of a sudden the secondary GPT partion is >>> borked. Any idea whats going on here ? >> >> Did you look to "dmesg -a" output for additional hints? >> What is system version? > > RELENG11 r337953 AMD64 > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-3 ATA SATA 3.x device > ada0: Serial Number DED9075313EC01677930 > ada0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 15272MB (31277232 512 byte sectors) > > Other than the message when I create the partition, nada > > GEOM: diskid/DISK-DED9075313EC01677930: the secondary GPT table is > corrupt or invalid. > GEOM: diskid/DISK-DED9075313EC01677930: using the primary only -- > recovery suggested. > > I tried different alignment options for the partition, and no changes. > Doing MBR however seems to work for some reason > > 0# gpart destroy -F ada0 > ada0 destroyed > 0# gpart create -s mbr ada0 > ada0 created > 0# gpart add -t freebsd ada0 > ada0s1 added > 0# ls -l /dev/ada0* > crw-r- 1 root operator - 0x4b Jan 19 23:59 /dev/ada0 > crw-r- 1 root operator - 0x7a Jan 20 22:09 /dev/ada0s1 > crw-r- 1 root operator - 0x7c Jan 20 22:09 /dev/ada0s1a > 0# newfs -U -O2 /dev/ada0s1a > /dev/ada0s1a: 15272.1MB (31277168 sectors) block size 32768, fragment > size 4096 > using 25 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. > with soft updates > super-block backups (for fsck_ffs -b #) at: > 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, > 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, > 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, > 28209472, 29491712, 30773952 > 0# > > > However, when I try to write to the disk, it crashes the box. I wonder > if this is a bad batch of mSata SSDs Hmmm > > > login: panic: ufs_dirbad: /mnt: bad dir ino 2 at offset 0: mangled entry It seems like faulty media to me: it silently returns bad data. There is an easy way to verify this just with naked eye: yes | dd bs=128k of=/dev/ada0 hd /dev/ada0 That is, hd(1) should write back only 3 lines of output: 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| * 0100 If not, the media if faulty. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gpart strangeness
On 8/20/2018 11:34 PM, Eugene Grosbein wrote: >> I was trying to create a single partition on a 16G mSata drive and >> whenever I add a partition, all of a sudden the secondary GPT partion is >> borked. Any idea whats going on here ? >> > > Did you look to "dmesg -a" output for additional hints? > What is system version? RELENG11 r337953 AMD64 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number DED9075313EC01677930 ada0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) ada0: Command Queueing enabled ada0: 15272MB (31277232 512 byte sectors) Other than the message when I create the partition, nada GEOM: diskid/DISK-DED9075313EC01677930: the secondary GPT table is corrupt or invalid. GEOM: diskid/DISK-DED9075313EC01677930: using the primary only -- recovery suggested. I tried different alignment options for the partition, and no changes. Doing MBR however seems to work for some reason 0# gpart destroy -F ada0 ada0 destroyed 0# gpart create -s mbr ada0 ada0 created 0# gpart add -t freebsd ada0 ada0s1 added 0# ls -l /dev/ada0* crw-r- 1 root operator - 0x4b Jan 19 23:59 /dev/ada0 crw-r- 1 root operator - 0x7a Jan 20 22:09 /dev/ada0s1 crw-r- 1 root operator - 0x7c Jan 20 22:09 /dev/ada0s1a 0# newfs -U -O2 /dev/ada0s1a /dev/ada0s1a: 15272.1MB (31277168 sectors) block size 32768, fragment size 4096 using 25 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952 0# However, when I try to write to the disk, it crashes the box. I wonder if this is a bad batch of mSata SSDs Hmmm login: panic: ufs_dirbad: /mnt: bad dir ino 2 at offset 0: mangled entry cpuid = 3 KDB: stack backtrace: #0 0x80642407 at kdb_backtrace+0x67 #1 0x805fbc37 at vpanic+0x177 #2 0x805fbab3 at panic+0x43 #3 0x808255d1 at ufs_lookup_ino+0xe21 #4 0x80929f6c at VOP_CACHEDLOOKUP_APV+0x7c #5 0x806a9c86 at vfs_cache_lookup+0xd6 #6 0x80929e4c at VOP_LOOKUP_APV+0x7c #7 0x806b3691 at lookup+0x6d1 #8 0x806b2b59 at namei+0x489 #9 0x806c9168 at kern_statat+0x98 #10 0x806c931c at sys_fstatat+0x2c #11 0x80889778 at amd64_syscall+0xa38 #12 0x8086a1fd at fast_syscall_common+0x101 Uptime: 1m6s PCEngines apu3 coreboot build 20170302 4080 MB ECC DRAM SeaBIOS (version rel-1.10.0.1) Press F10 key now for boot menu Booting from Hard Disk... F1 FreeBSD F2 FreeBSD F5 Drive 1 F6 PXE Boot: F1 /boot/config: -h -S115200 If I create a gpart, I can write to the disk, but there is corruption behind the scenes 0# gpart create -s gpt ada0 ada0 created 0# gpart add -t freebsd-ufs ada0 ada0p1 added 0# newfs newfs newfs_msdos 0# newfs -U -O2 /dev/ada0p1 /dev/ada0p1: 15272.0MB (31277152 sectors) block size 32768, fragment size 4096 using 25 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952 0# mount /dev/ada0p1 /mnt 0# dd if=/dev/urandom of=/mnt/test1 bs=4096k count=200 200+0 records in 200+0 records out 838860800 bytes transferred in 44.383275 secs (18900381 bytes/sec) 0# md5 /mnt/test1 MD5 (/mnt/test1) = 02fba9e2f3795f13b864c8613c8ae49e 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# dd if=/dev/urandom of=/mnt/test2 bs=4096k count=100 100+0 records in 100+0 records out 419430400 bytes transferred in 22.194061 secs (18898317 bytes/sec) 0# md5 /mnt/test1 MD5 (/mnt/test1) = 318ee3900564460b14e4e80e0bb8f358 0# ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gpart strangeness
21.08.2018 2:15, Mike Tancsa wrote: > I was trying to create a single partition on a 16G mSata drive and > whenever I add a partition, all of a sudden the secondary GPT partion is > borked. Any idea whats going on here ? > > > > 0# gpart destroy -F ada0 > ada0 destroyed > 0# gpart create -s GPT ada0 > ada0 created > 0# gpart add -t freebsd-ufs ada0 > GEOM: diskid/DISK-DEF30753136101678326: the secondary GPT table is > corrupt or invalid. > GEOM: diskid/DISK-DEF30753136101678326: using the primary only -- > recovery suggested. > ada0p1 added > 0# gpart list ada0 > Geom name: ada0 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 > last: 31277191 > first: 40 > entries: 128 > scheme: GPT > Providers: > 1. Name: ada0p1 >Mediasize: 16013901824 (15G) >Sectorsize: 512 >Stripesize: 0 >Stripeoffset: 20480 >Mode: r0w0e0 >efimedia: HD(1,GPT,2256d7c5-a4ad-11e8-aa7c-000db94b5a84,0x28,0x1dd4060) >rawuuid: 2256d7c5-a4ad-11e8-aa7c-000db94b5a84 >rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b >label: (null) >length: 16013901824 >offset: 20480 >type: freebsd-ufs >index: 1 >end: 31277191 >start: 40 > Consumers: > 1. Name: ada0 >Mediasize: 16013942784 (15G) >Sectorsize: 512 >Mode: r0w0e0 > > 0# Did you look to "dmesg -a" output for additional hints? What is system version? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
gpart strangeness
I was trying to create a single partition on a 16G mSata drive and whenever I add a partition, all of a sudden the secondary GPT partion is borked. Any idea whats going on here ? 0# gpart destroy -F ada0 ada0 destroyed 0# gpart create -s GPT ada0 ada0 created 0# gpart add -t freebsd-ufs ada0 GEOM: diskid/DISK-DEF30753136101678326: the secondary GPT table is corrupt or invalid. GEOM: diskid/DISK-DEF30753136101678326: using the primary only -- recovery suggested. ada0p1 added 0# gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 31277191 first: 40 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 16013901824 (15G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r0w0e0 efimedia: HD(1,GPT,2256d7c5-a4ad-11e8-aa7c-000db94b5a84,0x28,0x1dd4060) rawuuid: 2256d7c5-a4ad-11e8-aa7c-000db94b5a84 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 16013901824 offset: 20480 type: freebsd-ufs index: 1 end: 31277191 start: 40 Consumers: 1. Name: ada0 Mediasize: 16013942784 (15G) Sectorsize: 512 Mode: r0w0e0 0# -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
