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.hacksp...@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.hacksp...@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.and...@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-unsubscr...@freebsd.org"
