Date: Tue, 21 Aug 2018 20:51:58 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Mike Tancsa <mike@sentex.net>, FreeBSD-STABLE Mailing List <freebsd-stable@FreeBSD.org> Subject: Re: gpart strangeness Message-ID: <f56bf69b-45a2-e080-550c-2b08a6c2a28e@grosbein.net> In-Reply-To: <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <SATA SSD S9FM02.0> 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: 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| * 01000000 If not, the media if faulty.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f56bf69b-45a2-e080-550c-2b08a6c2a28e>