From owner-freebsd-stable@freebsd.org Mon May 8 16:10:07 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACF5AD63B91 for ; Mon, 8 May 2017 16:10:07 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10A7AB03 for ; Mon, 8 May 2017 16:10:06 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22e.google.com with SMTP id u65so90099124wmu.1 for ; Mon, 08 May 2017 09:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=S/CuxFSeXgbELbhazUNtdpY78z+EhSNn7B4/l//jajg=; b=DSrMm98oVmIxv2NSeXrUBV2bORqHVka46dWAlj91JtdrwyhUcXDkSQ09HcUXujl31j XGvlK2B45DJvuVEtJv5UcioiTqBvwtD/BvSzQpstoab1e5B9/M1hBheNRq0dMpO2A0Oy H1ZQHcjRf1YtFz2y3/sy/u2LskXXHphQIMEIttxg7HSSYQ14CyX+IMQTxukbLgQKuven JL7CrYOOjn0UiifRixjR33SDOeZdpEcra/QyT4CHAapt0dqaNGlKz6rztroVBgfL5ctu UqIZour6ZSV1hdr5j6gULJWc/wy+EYMAYd5oGAV4KMaR/mwOKg2h0uRtnZxyBB+LFt4P TOzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=S/CuxFSeXgbELbhazUNtdpY78z+EhSNn7B4/l//jajg=; b=LeU24ZLsMfUApF9FmM3l4cG7ET3sf1oEDLzUy2NKbOWzlfMcyRm3tJLaT6LarKkCMl Wi1OFoZbxh0Ufh3a4DDkYPIHjDc3Y2icH6E6uldfNjKLY9szMrydovuP01noj2kwZ+W0 coPupTFsHeD3GFsiuPsF9n06jRjfbTSxufDIyBZwEsy8YuJU52JYI/hk1XtIs/kKppN6 gLPjJlJI5Pjw2q29wV8OPpWts3J5nxiItqe3woqabF5EX5p/VcpJVw7Ri+OskLWfd7Dn iUV3FdOf3tvI6k2JD4Xy+Son1jpZDXRZLufpGudOeSGQb6Dp8YB2miuidWG4Yzu1lt0s MtSg== X-Gm-Message-State: AN3rC/46K8mUWp99Et4adqgjmmEb76uetLHrUSKhs+vjRBWqyEDxNNWH 0wVhs8tAYfuWVhN78rVPgg== X-Received: by 10.28.12.211 with SMTP id 202mr13155147wmm.32.1494259804591; Mon, 08 May 2017 09:10:04 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id c128sm10409488wmh.32.2017.05.08.09.10.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 09:10:03 -0700 (PDT) Subject: Re: Formatting a 4k disk on FreeBSD with ext2 To: freebsd-stable@freebsd.org References: From: Steven Hartland Message-ID: <6d8b1458-3f85-0e78-0e44-566f1a56d6fa@multiplay.co.uk> Date: Mon, 8 May 2017 17:10:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 16:10:07 -0000 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 > or > e2fsck -b 32768 > > 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 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 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 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"