Formatting a 4k disk on FreeBSD with ext2
Steven Hartland
killing at multiplay.co.uk
Mon May 8 16:10:07 UTC 2017
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 at 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 at 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 at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable
mailing list