Change sector size on existing partition

Change sector size on existing partition

[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

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[Brian Foster]

On Fri, Jan 23, 2015 at 08:04:44PM +0700, Dewangga Bachrul Alam wrote:
> 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.
> 

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

> [1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[Dewangga Bachrul Alam]

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.

On 01/23/2015 08:39 PM, Brian Foster wrote:
> On Fri, Jan 23, 2015 at 08:04:44PM +0700, Dewangga Bachrul Alam wrote:
>> 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.
>>
> 
> 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
> 
>> [1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[Brian Foster]

On Fri, Jan 23, 2015 at 08:46:59PM +0700, Dewangga Bachrul Alam wrote:
> 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?).

> 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.

>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

> On 01/23/2015 08:39 PM, Brian Foster wrote:
> > On Fri, Jan 23, 2015 at 08:04:44PM +0700, Dewangga Bachrul Alam wrote:
> >> 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.
> >>
> > 
> > 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
> > 
> >> [1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo
> >>
> >> _______________________________________________
> >> xfs mailing list
> >> xfs@oss.sgi.com
> >> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[Dewangga Bachrul Alam]

Hi,

On 01/23/2015 09:06 PM, Brian Foster wrote:
> On Fri, Jan 23, 2015 at 08:46:59PM +0700, Dewangga Bachrul Alam wrote:
>> 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?).
> 

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).

>> 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.
> 
> 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.

> Brian
> 
>> On 01/23/2015 08:39 PM, Brian Foster wrote:
>>> On Fri, Jan 23, 2015 at 08:04:44PM +0700, Dewangga Bachrul Alam wrote:
>>>> 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.
>>>>
>>>
>>> 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
>>>
>>>> [1] https://groups.google.com/forum/#!topic/tokudb-user/kvQFJLCmKwo
>>>>
>>>> _______________________________________________
>>>> xfs mailing list
>>>> xfs@oss.sgi.com
>>>> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[Eric Sandeen]

On 1/23/15 7:04 AM, Dewangga Bachrul Alam wrote:
> 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

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 <sandeen@sandeen.net>
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.
    
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[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)

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?

On 01/23/2015 10:29 PM, Eric Sandeen wrote:
> On 1/23/15 7:04 AM, Dewangga Bachrul Alam wrote:
>> 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
> 
> 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 <sandeen@sandeen.net>
> 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.
>     
>     Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[Eric Sandeen]

On 1/23/15 9:40 AM, Dewangga Bachrul Alam wrote:
> 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

so xfsprogs v3.1.1

This went into v3.1.8:

commit 287d168b550857ce40e04b5f618d7eb91b87022f
Author: Eric Sandeen <sandeen@sandeen.net>
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.
    
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>

but was backported to the RHEL6 xfsprogs:

* Tue Sep 25 2012 Eric Sandeen <sandeen@redhat.com> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[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.

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.

On 01/23/2015 10:49 PM, Eric Sandeen wrote:
> On 1/23/15 9:40 AM, Dewangga Bachrul Alam wrote:
>> 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
> 
> so xfsprogs v3.1.1
> 
> This went into v3.1.8:
> 
> commit 287d168b550857ce40e04b5f618d7eb91b87022f
> Author: Eric Sandeen <sandeen@sandeen.net>
> 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.
>     
>     Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>     Reviewed-by: Dave Chinner <dchinner@redhat.com>
> 
> but was backported to the RHEL6 xfsprogs:
> 
> * Tue Sep 25 2012 Eric Sandeen <sandeen@redhat.com> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Change sector size on existing partition

[Eric Sandeen]

On 1/23/15 10:26 AM, Dewangga Bachrul Alam wrote:
> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs