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
>>>
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"
Am 08.05.2017 um 17:42 schrieb HSR Hackspace:> 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--------->Please show the output of $ env LANG= LANGUAGE= LC_ALL=C mkfs.ext3 -V It should print 1.43.4 for the program _and the library_ (the latter isn't shown above). Then, please run mkfs.ext3 under truss, or under ktrace, and upload the truss or kdump log somewhere and post the URL. Do not mail the log, it's gonna be too big. "Invalid argument" aka EINVAL looks like misaligned access. Now, diskinfo provided the right sectorsize (4096), which it - as of FreeBSD 10.3 - obtains with ioctl(fd, DIOCGSECTORSIZE, §orsize), where sectorsize is a u_int, and unsigned int. Which RAID device is it, what's its structure?