Date: Mon, 8 May 2017 17:10:07 +0100 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-stable@freebsd.org Subject: Re: Formatting a 4k disk on FreeBSD with ext2 Message-ID: <6d8b1458-3f85-0e78-0e44-566f1a56d6fa@multiplay.co.uk> In-Reply-To: <CAJN=9WFSzLC28%2B353OiCzMzZvHuNP3uU47SBw_rJs0_BSpqEjQ@mail.gmail.com> References: <CAJN=9WFSzLC28%2B353OiCzMzZvHuNP3uU47SBw_rJs0_BSpqEjQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
That looks like its trying to do an erase of the sectors, which is likely failing due to the device being a HW RAID, have you tried with nodiscard set? On 08/05/2017 16:42, HSR Hackspace wrote: > Hi folks; > > I'm trying to format a 300 GB partition on x86_64 box running running > BSD 10.1 with HW RAID configuration. All my attempt so far have > failed. Below are the logs for same. > > Logs: > > 1. pod1208-wsa07:rtestuser 106] ./mkfs.ext3 /dev/da0p7 > mke2fs 1.43.4 (31-Jan-2017) > Warning: could not erase sector 2: Invalid argument---------> > Creating filesystem with 78643200 4k blocks and 19660800 inodes > Filesystem UUID: c31fab56-f690-4313-a09c-9a585224caea > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, > 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 > > Allocating group tables: done > Warning: could not read block 0: Invalid argument -----------> > Warning: could not erase sector 0: Invalid argument > Writing inode tables: done > Creating journal (262144 blocks): done > Writing superblocks and filesystem accounting information: 0/2400 > Warning, had trouble writing out superblocks. > pod1208-wsa07:rtestuser 107] > > 2. > pod1208-wsa07:rtestuser 32] ./fsck.ext2 -v -b 4096 /dev/da0p7 > e2fsck 1.43.4 (31-Jan-2017) > ./fsck.ext2: Invalid argument while trying to open /dev/da0p7 > > The superblock could not be read or does not describe a valid ext2/ext3/ext4 > filesystem. If the device is valid and it really contains an ext2/ext3/ext4 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate superblock: > e2fsck -b 8193 <device> > or > e2fsck -b 32768 <device> > > pod1208-wsa07:rtestuser 33] > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 3. > pod1208-wsa07:rtestuser 43] ./dumpe2fs /dev/da0p7 > dumpe2fs 1.43.4 (31-Jan-2017) > ./dumpe2fs: Invalid argument while trying to open /dev/da0p7 > Couldn't find valid filesystem superblock. > pod1208-wsa07:rtestuser 44] > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 4. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > pod1208-wsa07:rtestuser 29] ./mkfs.ext2 -b 4096 /dev/da0p7 > mke2fs 1.43.4 (31-Jan-2017) > Warning: could not erase sector 2: Invalid argument > Creating filesystem with 78643200 4k blocks and 19660800 inodes > Filesystem UUID: 015a85a4-7db9-4767-869c-7bab11c9074e > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, > 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 > > Allocating group tables: done > Warning: could not read block 0: Invalid argument > Warning: could not erase sector 0: Invalid argument > Writing inode tables: done > Writing superblocks and filesystem accounting information: 0/2400 > Warning, had trouble writing out superblocks. > pod1208-wsa07:rtestuser 30] > > > 5. > pod1208-wsa07:rtestuser 31] camcontrol identify da0 > camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed > pod1208-wsa07:rtestuser 32] > > 6. > > pod1208-wsa07:rtestuser 24] diskinfo -c da0 > da0 > 4096 # sectorsize > 1197995982848 # mediasize in bytes (1.1T) > 292479488 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 18206 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. > > I/O command overhead: > ^[OA time to read 10MB block 0.004811 sec = 0.000 msec/sector > time to read 20480 sectors 0.491882 sec = 0.024 msec/sector > calculated command overhead = 0.024 msec/sector > > pod1208-wsa07:rtestuser 25] diskinfo -c da0p7 > da0p7 > 4096 # sectorsize > 322122547200 # mediasize in bytes (300G) > 78643200 # mediasize in sectors > 0 # stripesize > 1493762048 # stripeoffset > 4895 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. > > I/O command overhead: > time to read 10MB block 0.004860 sec = 0.000 msec/sector > time to read 20480 sectors 0.495921 sec = 0.024 msec/sector > calculated command overhead = 0.024 msec/sector > > 7. > pod1208-wsa07:rtestuser 21] gpart show -l > 6 292479477 da0 GPT (1.1T) > 6 10 - free - (40K) > 16 128 1 (null) (512K) > 144 262144 2 efi (1.0G) > 262288 1048576 3 rootfs (4.0G) > 1310864 2097152 4 swap (8.0G) > 3408016 1048576 5 nextroot (4.0G) > 4456592 102400 6 var (400M) > 4558992 78643200 7 raw (300G) > 83202192 524288 8 godspeed (2.0G) > 83726480 208752992 9 data (796G) > 292479472 11 - free - (44K) > > Let me know if anyone have formatted 4k drive with ext2 recently. If > yes from where should I start debugging this issue. Does above logs > give hint on what could be going wrong here? > > > TIA > _SP > > > On Mon, May 8, 2017 at 3:11 PM, HSR Hackspace <hsr.hackspace@gmail.com> wrote: >> Sorry I used wrong device in above log. Below is correct data. >> >> >> pod1208-wsa07:rtestuser 21] gpart show -l >> => 6 292479477 da0 GPT (1.1T) >> 6 10 - free - (40K) >> 16 128 1 (null) (512K) >> 144 262144 2 efi (1.0G) >> 262288 1048576 3 rootfs (4.0G) >> 1310864 2097152 4 swap (8.0G) >> 3408016 1048576 5 nextroot (4.0G) >> 4456592 102400 6 var (400M) >> 4558992 78643200 7 raw (300G) >> 83202192 524288 8 godspeed (2.0G) >> 83726480 208752992 9 data (796G) >> 292479472 11 - free - (44K) >> >> pod1208-wsa07:rtestuser 22] camcontrol identify da0p7 >> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed >> cam_lookup_pass: No such file or directory >> cam_lookup_pass: either the pass driver isn't in your kernel >> cam_lookup_pass: or da0p7 doesn't exist >> pod1208-wsa07:rtestuser 23] >> pod1208-wsa07:rtestuser 23] >> pod1208-wsa07:rtestuser 23] camcontrol identify da0 >> camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed >> pod1208-wsa07:rtestuser 24] >> >> >> pod1208-wsa07:rtestuser 24] diskinfo -c da0 >> da0 >> 4096 # sectorsize >> 1197995982848 # mediasize in bytes (1.1T) >> 292479488 # mediasize in sectors >> 0 # stripesize >> 0 # stripeoffset >> 18206 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >> >> I/O command overhead: >> ^[OA time to read 10MB block 0.004811 sec = 0.000 msec/sector >> time to read 20480 sectors 0.491882 sec = 0.024 msec/sector >> calculated command overhead = 0.024 msec/sector >> >> pod1208-wsa07:rtestuser 25] diskinfo -c da0p7 >> da0p7 >> 4096 # sectorsize >> 322122547200 # mediasize in bytes (300G) >> 78643200 # mediasize in sectors >> 0 # stripesize >> 1493762048 # stripeoffset >> 4895 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >> >> I/O command overhead: >> time to read 10MB block 0.004860 sec = 0.000 msec/sector >> time to read 20480 sectors 0.495921 sec = 0.024 msec/sector >> calculated command overhead = 0.024 msec/sector >> >> >> -SP >> >> On Mon, May 8, 2017 at 11:31 AM, HSR Hackspace <hsr.hackspace@gmail.com> wrote: >>> Hi Andree; >>> >>> Thanks for your prompt reply. Please find below the logs you requested. >>> >>> T & R >>> _SP >>> ++++++++++++++++++++++++++++++++++++++++++= >>> pod1208-wsa07:rtestuser 4] diskinfo -c /dev/da0p7 >>> /dev/da0p7 >>> 4096 # sectorsize >>> 322122547200 # mediasize in bytes (300G) >>> 78643200 # mediasize in sectors >>> 0 # stripesize >>> 1493762048 # stripeoffset >>> 4895 # Cylinders according to firmware. >>> 255 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >>> >>> I/O command overhead: >>> time to read 10MB block 0.026713 sec = 0.001 msec/sector >>> time to read 20480 sectors 0.494624 sec = 0.024 msec/sector >>> calculated command overhead = 0.023 msec/sector >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> pod1208-wsa07:rtestuser 5] diskinfo -c /dev/da0 >>> /dev/da0 >>> 4096 # sectorsize >>> 1197995982848 # mediasize in bytes (1.1T) >>> 292479488 # mediasize in sectors >>> 0 # stripesize >>> 0 # stripeoffset >>> 18206 # Cylinders according to firmware. >>> 255 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >>> >>> I/O command overhead: >>> time to read 10MB block 0.039394 sec = 0.002 msec/sector >>> time to read 20480 sectors 0.485778 sec = 0.024 msec/sector >>> calculated command overhead = 0.022 msec/sector >>> >>> pod1208-wsa07:rtestuser 6] >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> pod1208-wsa07:rtestuser 6] camcontrol identify da1 >>> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed ----------------> >>> cam_lookup_pass: No such file or directory >>> cam_lookup_pass: either the pass driver isn't in your kernel >>> cam_lookup_pass: or da1 doesn't exist >>> pod1208-wsa07:rtestuser 7] >>> >>> >>> >>> >>> >>> On Sat, May 6, 2017 at 11:07 PM, Matthias Andree <matthias.andree@gmx.de> wrote: >>>> Am 06.05.2017 um 16:47 schrieb Theodore Ts'o: >>>>> On Fri, May 05, 2017 at 10:44:52PM +0530, HSR Hackspace wrote: >>>>>> Thanks for prompt reply. I am sorry I forgot to mention that I am >>>>>> doing all this on a FreeBSD 10.1 If you argument is till valid is >>>>>> there anyway I confirm it? If HW raid is advertising 512 how is disk >>>>>> info able to read correct data? >>>>> Sorry, no clue. I don't really use FreeBSD myself. >>>>> >>>>> I've added Matthias to the cc list since he's the person who maintains >>>>> e2fsprogs for the FreeBSD ports collection. I know how to fire up a >>>>> FreeBSD VM on Google Compute Engine, and check to make sure e2fsprogs >>>>> can build and pass the regression tests, but that is really the extent >>>>> of my FreeBSD skills. >>>>> >>>>> Mattias --- the user is trying to create an ext2 file system on a >>>>> hardware raid device which is using advanced format (4k sector) HDD's. >>>>> >>>>> The problem could be in libext2fs's attempt to find out the logical >>>>> and physical sector size (we may not be using the right FreeBSD >>>>> ioctl's to get that information), or it could be some bug in the >>>>> Hardware Raid controller, or perhaps even in FreeBSD's handling of >>>>> advanced format drives (although I really doubt that last). >>>> Greetings, >>>> >>>> I seem to recall that we pinged FreeBSD developers about getting the >>>> physical, as opposed to the logical, block size of the device (a few >>>> months ago), some disk/controller combinations exposing this via stripe >>>> size, but there wasn't a consistent way of obtaining that at the time. >>>> >>>> Now, FreeBSD 10.1 has gone out of support, and we need kernel hacker >>>> support here for the right ioctl()s. >>>> I think the best approach is to ask the same question for FreeBSD 10.3 >>>> and 11.0 and see what and how far we get. >>>> >>>> HSR, what do you get running camcontrol identify, and diskinfo, on your >>>> disk? For example (replace da1 by your actual disk device): >>>> >>>> camcontrol identify da1 >>>> >>>> diskinfo da1 >>>> >>>> Best regards, >>>> Matthias >>>> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6d8b1458-3f85-0e78-0e44-566f1a56d6fa>