Skip to contentSkip to conversation

Change sector size on existing partition

DISCUSSION Dewangga Bachrul Alam 3 participants 10 messages Jan 23, 2015

lore
Share & tools
lore
#0 lore raw

Hi,

I'm new to XFS, I have RAID-10 array with 4 disk, when I check with xfs_info, the information print like this.

$ xfs_info /var/lib/mysql
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Is it possible to change sectsz value to 512 without re-format it? Or any suggestion? I have issue with current sector size, my TokuDB engines[1] can't start because of this.

[1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#1 lore raw
Quoted 16 lines · Dewangga Bachrul Alam

Hi,

I'm new to XFS, I have RAID-10 array with 4 disk, when I check with xfs_info, the information print like this.

$ xfs_info /var/lib/mysql
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Quoted 4 lines

Is it possible to change sectsz value to 512 without re-format it? Or any suggestion? I have issue with current sector size, my TokuDB engines[1] can't start because of this.

The only way to set things like sector size, block size, etc. is to reformat. I believe the default sector size is dependent on the physical device. You might want to report the following from your array device and perhaps from some or all of the member devices:

blockdev --getss --getpbsz --getiomin --getioopt <device>

Brian

Quoted 6 lines

[1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#2 lore raw

Hi,

The device reported like this :

$ blockdev --getss --getpbsz --getiomin --getioopt /dev/dm-3
512
4096
4096
0

Then, the sector size should be 512. Don't know why it can be 4096. :( I will try to backup them and reformat. Any suggestion for formating on raid-10 array? The device is 4 x 1TB drives.

Quoted 22 lines · Brian Foster
Quoted 16 lines · Dewangga Bachrul Alam

Hi,

I'm new to XFS, I have RAID-10 array with 4 disk, when I check with xfs_info, the information print like this.

$ xfs_info /var/lib/mysql
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Quoted 4 lines

Is it possible to change sectsz value to 512 without re-format it? Or any suggestion? I have issue with current sector size, my TokuDB engines[1] can't start because of this.

Quoted 15 lines

The only way to set things like sector size, block size, etc. is to reformat. I believe the default sector size is dependent on the physical device. You might want to report the following from your array device and perhaps from some or all of the member devices:

blockdev --getss --getpbsz --getiomin --getioopt <device>

Brian

Quoted 6 lines

[1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#3 lore raw
Quoted 10 lines · Dewangga Bachrul Alam

Hi,

The device reported like this :

$ blockdev --getss --getpbsz --getiomin --getioopt /dev/dm-3
512
4096
4096
0

What is dm-3? Is that a logical volume based on a volume group on top of your physical array? It might be good to get the equivalent data for the array device (md?) and at least one of the physical devices (sd?).

Quoted 4 lines

Then, the sector size should be 512. Don't know why it can be 4096. :( I will try to backup them and reformat. Any suggestion for formating on raid-10 array? The device is 4 x 1TB drives.

According to the above you have 4k physical sectors and 512b logical sectors. IIUC, this means mkfs will use the physical size by default, but you can specify and the device can handle down to 512 sectors.

Quoted 1 line

From skimming through the link posted earlier, it sounds like you have

an application that has a hardcoded dependency on 512b direct I/O requirements (e.g., buffer alignment) rather than being configurable..? Can you disable direct I/O and verify whether that works? Regardless, it might be wise to test out this 512b sector configuration (perhaps with a single or spare drive?) and verify this fixes the problem you're trying to solve before reconfiguring everything.

Brian

Quoted 30 lines · Brian Foster
Quoted 29 lines · Dewangga Bachrul Alam
Quoted 16 lines

Hi,

I'm new to XFS, I have RAID-10 array with 4 disk, when I check with xfs_info, the information print like this.

$ xfs_info /var/lib/mysql
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Quoted 4 lines

Is it possible to change sectsz value to 512 without re-format it? Or any suggestion? I have issue with current sector size, my TokuDB engines[1] can't start because of this.

The only way to set things like sector size, block size, etc. is to reformat. I believe the default sector size is dependent on the physical device. You might want to report the following from your array device and perhaps from some or all of the member devices:

blockdev --getss --getpbsz --getiomin --getioopt <device>

Quoted 8 lines
Quoted 8 lines

Brian

Quoted 6 lines

[1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#4 lore raw

Hi,

Quoted 12 lines · Brian Foster
Quoted 10 lines · Dewangga Bachrul Alam

Hi,

The device reported like this :

$ blockdev --getss --getpbsz --getiomin --getioopt /dev/dm-3
512
4096
4096
0
Quoted 4 lines

What is dm-3? Is that a logical volume based on a volume group on top of your physical array? It might be good to get the equivalent data for the array device (md?) and at least one of the physical devices (sd?).

dm-3 is logical partition, not my physical array. Here is my partition table :

--
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk

├─sda1                                   8:1    0  500M  0 part /boot
└─sda2                                   8:2    0  1.8T  0 part
  ├─vg_catalystdb01-lv_root (dm-0)     253:0    0   50G  0 lvm  /
  ├─vg_catalystdb01-lv_swap (dm-1)     253:1    0 31.5G  0 lvm  [SWAP]
  ├─vg_catalystdb01-lv_home (dm-2)     253:2    0 48.8G  0 lvm  /home
  ├─vg_catalystdb01-lv_database (dm-3) 253:3    0 97.7G  0 lvm
/var/lib/mysql
  ├─vg_catalystdb01-lv_tmp (dm-4)      253:4    0  3.9G  0 lvm  /tmp
  ├─vg_catalystdb01-lv_var (dm-5)      253:5    0 19.5G  0 lvm  /var
  ├─vg_catalystdb01-lv_audit (dm-6)    253:6    0  3.9G  0 lvm

/var/log/audit
└─vg_catalystdb01-lv_log (dm-7) 253:7 0 7.8G 0 lvm /var/log
--

XFS file system is only mounted on vg_catalystdb01-lv_database (dm-3).

Quoted 9 lines
Quoted 4 lines

Then, the sector size should be 512. Don't know why it can be 4096. :( I will try to backup them and reformat. Any suggestion for formating on raid-10 array? The device is 4 x 1TB drives.

According to the above you have 4k physical sectors and 512b logical sectors. IIUC, this means mkfs will use the physical size by default, but you can specify and the device can handle down to 512 sectors.

Quoted 8 lines

From skimming through the link posted earlier, it sounds like you have an application that has a hardcoded dependency on 512b direct I/O requirements (e.g., buffer alignment) rather than being configurable..? Can you disable direct I/O and verify whether that works? Regardless, it might be wise to test out this 512b sector configuration (perhaps with a single or spare drive?) and verify this fixes the problem you're trying to solve before reconfiguring everything.

If I disable directio, the application works well.

Then, I've reformat the existing partition, and enable directio parameter. It's works. It's the new result.

$ xfs_info /dev/dm-3
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Thanks bro.

Quoted 40 lines

Brian

Quoted 38 lines · Brian Foster
Quoted 37 lines · Dewangga Bachrul Alam
Quoted 16 lines

Hi,

I'm new to XFS, I have RAID-10 array with 4 disk, when I check with xfs_info, the information print like this.

$ xfs_info /var/lib/mysql
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Quoted 4 lines

Is it possible to change sectsz value to 512 without re-format it? Or any suggestion? I have issue with current sector size, my TokuDB engines[1] can't start because of this.

The only way to set things like sector size, block size, etc. is to reformat. I believe the default sector size is dependent on the physical device. You might want to report the following from your array device and perhaps from some or all of the member devices:

blockdev --getss --getpbsz --getiomin --getioopt <device>

Brian

Quoted 6 lines

[1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#5 lore raw
In reply to Dewangga Bachrul Alam
Quoted 16 lines · Dewangga Bachrul Alam

Hi,

I'm new to XFS, I have RAID-10 array with 4 disk, when I check with xfs_info, the information print like this.

$ xfs_info /var/lib/mysql
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Quoted 5 lines

Is it possible to change sectsz value to 512 without re-format it? Or any suggestion? I have issue with current sector size, my TokuDB engines[1] can't start because of this.

[1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo

You almost certainly need this commit to resolve the issue.

You didn't say here what kernel you were using, but from your other post it looks like CentOS 6.4. Are you using stock xfsprogs from centos6.4 as well? I don't remember if it chooses 4k sectors for 4k physical block devices or not; unless you have a custom xfsprogs version or overrode sector size at mkfs time, I guess it must.

commit 7c71ee78031c248dca13fc94dea9a4cc217db6cf

Author: Eric Sandeen <[email protected]>
Date:   Tue Jan 21 16:46:23 2014 -0600

xfs: allow logical-sector sized O_DIRECT

Some time ago, mkfs.xfs started picking the storage physical sector size as the default filesystem "sector size" in order to avoid RMW costs incurred by doing IOs at logical sector size alignments.

However, this means that for a filesystem made with i.e. a 4k sector size on an "advanced format" 4k/512 disk, 512-byte direct IOs are no longer allowed. This means that XFS has essentially turned this AF drive into a hard 4K device, from the filesystem on up.

XFS's mkfs-specified "sector size" is really just controlling the minimum size & alignment of filesystem metadata.

There is no real need to tightly couple XFS's minimal metadata size to the minimum allowed direct IO size; XFS can continue doing metadata in optimal sizes, but still allow smaller DIOs for apps which issue them, for whatever reason.

This patch adds a new field to the xfs_buftarg, so that we now track 2 sizes:

1) The metadata sector size, which is the minimum unit and alignment of IO which will be performed by metadata operations.
2) The device logical sector size

The first is used internally by the file system for metadata alignment and IOs.
The second is used for the minimum allowed direct IO alignment.

This has passed xfstests on filesystems made with 4k sectors, including when run under the patch I sent to ignore XFS_IOC_DIOINFO, and issue 512 DIOs anyway. I also directly tested end of block behavior on preallocated, sparse, and existing files when we do a 512 IO into a 4k file on a 4k-sector filesystem, to be sure there were no unexpected behaviors.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#6 lore raw

Hi,

I'm sorry, didnt fill any information here, but here is my nodes details.

$ uname -a
Linux catalyst-db01.jkt3d.xxx 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec
17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
CentOS release 6.6 (Final)

The xfs and partition table build from anaconda from first install, instalation came from CentOS 6.6. But it's weird, only this node has 4k sector size, the others is 512.

catalyst-db01$ yum history info 1 | grep xfsprogs | fpaste Uploading (0.2KiB)...
http://ur1.ca/jihyu -> http://paste.fedoraproject.org/173606/27434142

catalyst-db02$ yum history info 1 | grep xfsprogs | fpaste Uploading (0.2KiB)...
http://ur1.ca/jihzp -> http://paste.fedoraproject.org/173608/27517142

Is it bug?

Quoted 76 lines · Eric Sandeen
Quoted 16 lines · Dewangga Bachrul Alam

Hi,

I'm new to XFS, I have RAID-10 array with 4 disk, when I check with xfs_info, the information print like this.

$ xfs_info /var/lib/mysql
meta-data=/dev/mapper/vg_catalystdb01-lv_database isize=256
agcount=16, agsize=1600000 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=25600000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=12500, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Quoted 5 lines

Is it possible to change sectsz value to 512 without re-format it? Or any suggestion? I have issue with current sector size, my TokuDB engines[1] can't start because of this.

[1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo

You almost certainly need this commit to resolve the issue.

You didn't say here what kernel you were using, but from your other post it looks like CentOS 6.4. Are you using stock xfsprogs from centos6.4 as well? I don't remember if it chooses 4k sectors for 4k physical block devices or not; unless you have a custom xfsprogs version or overrode sector size at mkfs time, I guess it must.

commit 7c71ee78031c248dca13fc94dea9a4cc217db6cf

Author: Eric Sandeen <[email protected]>
Date:   Tue Jan 21 16:46:23 2014 -0600

xfs: allow logical-sector sized O_DIRECT

Some time ago, mkfs.xfs started picking the storage physical sector size as the default filesystem "sector size" in order to avoid RMW costs incurred by doing IOs at logical sector size alignments.

However, this means that for a filesystem made with i.e. a 4k sector size on an "advanced format" 4k/512 disk, 512-byte direct IOs are no longer allowed. This means that XFS has essentially turned this AF drive into a hard 4K device, from the filesystem on up.

XFS's mkfs-specified "sector size" is really just controlling the minimum size & alignment of filesystem metadata.

There is no real need to tightly couple XFS's minimal metadata size to the minimum allowed direct IO size; XFS can continue doing metadata in optimal sizes, but still allow smaller DIOs for apps which issue them, for whatever reason.

This patch adds a new field to the xfs_buftarg, so that we now track 2 sizes:

1) The metadata sector size, which is the minimum unit and alignment of IO which will be performed by metadata operations.
2) The device logical sector size

The first is used internally by the file system for metadata alignment and IOs.
The second is used for the minimum allowed direct IO alignment.

This has passed xfstests on filesystems made with 4k sectors, including when run under the patch I sent to ignore XFS_IOC_DIOINFO, and issue 512 DIOs anyway. I also directly tested end of block behavior on preallocated, sparse, and existing files when we do a 512 IO into a 4k file on a 4k-sector filesystem, to be sure there were no unexpected behaviors.

Quoted 3 lines

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Reviewed-by Dave Chinner
#7 lore raw
Quoted 11 lines · Dewangga Bachrul Alam

Hi,

I'm sorry, didnt fill any information here, but here is my nodes details.

$ uname -a
Linux catalyst-db01.jkt3d.xxx 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec
17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
CentOS release 6.6 (Final)
Quoted 7 lines

The xfs and partition table build from anaconda from first install, instalation came from CentOS 6.6. But it's weird, only this node has 4k sector size, the others is 512.

catalyst-db01$ yum history info 1 | grep xfsprogs | fpaste Uploading (0.2KiB)...
http://ur1.ca/jihyu -> http://paste.fedoraproject.org/173606/27434142

so xfsprogs v3.1.1

This went into v3.1.8:

commit 287d168b550857ce40e04b5f618d7eb91b87022f

Author: Eric Sandeen <[email protected]>
Date:   Thu Mar 1 22:46:35 2012 -0600

mkfs.xfs: properly handle physical sector size

This splits the fs_topology structure "sectorsize" into logical & physical, and gets both via blkid_get_topology().

This primarily allows us to default to using the physical sectorsize for mkfs's "sector size" value, the fundamental size of any IOs the filesystem will perform.

We reduce mkfs.xfs's "sector size" to logical if a block size < physical sector size is specified. This is suboptimal, but permissable.

For block size < sector size, differentiate the error message based on whether the sector size was manually specified, or deduced.

but was backported to the RHEL6 xfsprogs:

* Tue Sep 25 2012 Eric Sandeen <[email protected]> 3.1.1-8
- mkfs.xfs: better handle misaligned 4k devices (#836433)
- mkfs.xfs: default to physical sectorsize (#836433)

So, not *exactly* a bug, because the assumption that 512-byte DIO will always work is not a good one, but the commit I mentioned in my first email will let 512-byte DIOs work again.

I'd tell you to file a bug with your RHEL support people, but Centos ... ;) We probably should get that kernel commit into RHEL6 if possible. I'm kind of surprised we haven't seen other reports.

But, if you ever wind up with hard 4k/4k drives, your database still won't work. On any filesystem. :)

If you don't mind following up with this informtation in the other forum, that might help others.

-Eric

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#8 lore raw

Hi,

Thanks for your kind, but I don't know how to reproduce the errors, it happens randomly. I try to reproduce on VM but nothing helps, I can't create raid array on VM. :)

But, I'm quite sure there is miscalculation or something else that make 4k sector size on RAID-10 array.

And anyway, I found something interesting, it happens on my old development server too, but I didn't use the application like on new box. So it's no problem.

$ xfs_info /database/mysql
meta-data=/dev/mapper/vg_agnirudra-lv_database isize=256    agcount=32,
agsize=7629824 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=244154368, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=119216, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

It's software raid-1 array. Here is the partition table.

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdc 8:32 0 931.5G 0 disk

└─sdc1                                  8:33   0 931.5G  0 part
  └─md0                                 9:0    0 931.4G  0 raid1
    └─vg_agnirudra-lv_database (dm-2) 253:2    0 931.4G  0 lvm   /database
sda                                     8:0    0 279.5G  0 disk
├─sda1                                  8:1    0   500M  0 part  /boot
└─sda2                                  8:2    0   279G  0 part
  ├─vg_os-lv_root (dm-0)              253:0    0   271G  0 lvm   /
  └─vg_os-lv_swap (dm-1)              253:1    0     8G  0 lvm   [SWAP]
sdb                                     8:16   0 931.5G  0 disk
└─sdb1                                  8:17   0 931.5G  0 part
  └─md0                                 9:0    0 931.4G  0 raid1
    └─vg_agnirudra-lv_database (dm-2) 253:2    0 931.4G  0 lvm   /database
sr0                                    11:0    1  1024M  0 rom
$ uname -a
Linux agnirudra.xxx 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
CentOS release 6.5 (Final)
$ yum history info 1 | grep xfsprogs | fpaste
Uploading (0.2KiB)...
http://ur1.ca/jiikv -> http://paste.fedoraproject.org/173636/14220298

It's came from CentOS 6.4, xfsprogs default stock 6.4, as you mentioned before.

Quoted 62 lines · Eric Sandeen
Quoted 11 lines · Dewangga Bachrul Alam

Hi,

I'm sorry, didnt fill any information here, but here is my nodes details.

$ uname -a
Linux catalyst-db01.jkt3d.xxx 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec
17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
CentOS release 6.6 (Final)
Quoted 7 lines

The xfs and partition table build from anaconda from first install, instalation came from CentOS 6.6. But it's weird, only this node has 4k sector size, the others is 512.

catalyst-db01$ yum history info 1 | grep xfsprogs | fpaste Uploading (0.2KiB)...
http://ur1.ca/jihyu -> http://paste.fedoraproject.org/173606/27434142

so xfsprogs v3.1.1

This went into v3.1.8:

commit 287d168b550857ce40e04b5f618d7eb91b87022f

Author: Eric Sandeen <[email protected]>
Date:   Thu Mar 1 22:46:35 2012 -0600

mkfs.xfs: properly handle physical sector size

This splits the fs_topology structure "sectorsize" into logical & physical, and gets both via blkid_get_topology().

This primarily allows us to default to using the physical sectorsize for mkfs's "sector size" value, the fundamental size of any IOs the filesystem will perform.

We reduce mkfs.xfs's "sector size" to logical if a block size < physical sector size is specified. This is suboptimal, but permissable.

For block size < sector size, differentiate the error message based on whether the sector size was manually specified, or deduced.

but was backported to the RHEL6 xfsprogs:

* Tue Sep 25 2012 Eric Sandeen <[email protected]> 3.1.1-8
- mkfs.xfs: better handle misaligned 4k devices (#836433)
- mkfs.xfs: default to physical sectorsize (#836433)

So, not *exactly* a bug, because the assumption that 512-byte DIO will always work is not a good one, but the commit I mentioned in my first email will let 512-byte DIOs work again.

I'd tell you to file a bug with your RHEL support people, but Centos ... ;) We probably should get that kernel commit into RHEL6 if possible. I'm kind of surprised we haven't seen other reports.

Quoted 8 lines

But, if you ever wind up with hard 4k/4k drives, your database still won't work. On any filesystem. :)

If you don't mind following up with this informtation in the other forum, that might help others.

-Eric

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#9 lore raw
Quoted 8 lines · Dewangga Bachrul Alam

Hi,

Thanks for your kind, but I don't know how to reproduce the errors, it happens randomly. I try to reproduce on VM but nothing helps, I can't create raid array on VM. :)

But, I'm quite sure there is miscalculation or something else that make 4k sector size on RAID-10 array.

Well, as Brian mentioned in the other part of the thread, it's the logical and physical sector sizes that matter. mkfs.xfs simply acts on what the device reports (i.e. the --getpbsz value).

If for some reason your RAID-10 array is reporting 4k/4k and you don't expect that, you'll need to go digging through the block device configuration and maybe ask questions of those communities, too.

It seems like you have interesting device stacking; use the blockdev command to check logical & physical sector size at each layer starting at the disk itself, and work your way up.

-Eric

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs