Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Alignment\s+size\?\s*$/: 11 ]

Total 11 documents matching your query.

1. Alignment size? (score: 1)
Author: Michael Tokarev <mjt@xxxxxxxxxx>
Date: Fri, 13 Aug 2010 02:10:39 +0400
Hello. I used XFS for a long time on many different servers, and it works well. But now I encountered an.. unexpected problem. The question is: on one of our servers, XFS requires different alignment
/archives/xfs/2010-08/msg00117.html (7,039 bytes)

2. Re: Alignment size? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 09:49:11 +1000
It'll be a filesystem set up with a 4k sector size, then. Check the output of xfs_info. A clear case of application failure. I guess Oracle have some work to do to support 4k sector drives where they
/archives/xfs/2010-08/msg00118.html (8,232 bytes)

3. Re: Alignment size? (score: 1)
Author: Michael Tokarev <mjt@xxxxxxxxxx>
Date: Fri, 13 Aug 2010 10:24:46 +0400
yes, xfs_info reports sectsz=4096, I noticed this yesterday. Sure thing, that's oracle10, and at least at that time there was no way to determine the size of I/O in a generic way. Now there is, and I
/archives/xfs/2010-08/msg00119.html (11,300 bytes)

4. Re: Alignment size? (score: 1)
Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 05:27:55 -0500
Michael Tokarev put forth on 8/13/2010 1:24 AM: 4096 is the default block size and has been since at least 2.6.26 when I started using XFS. From "man mkfs.xfs": OPTIONS -b block_size_options This opt
/archives/xfs/2010-08/msg00122.html (9,721 bytes)

5. Re: Alignment size? (score: 1)
Author: Michael Tokarev <mjt@xxxxxxxxxx>
Date: Fri, 13 Aug 2010 15:00:09 +0400
This is block size. But XFS_IOC_DIOINFO returns _sector_ size. All other XFS filesystems we have are made with the same 4096 _block_ size. That was the wrong question. The right one is about _sector_
/archives/xfs/2010-08/msg00124.html (10,307 bytes)

6. Re: Alignment size? (score: 1)
Author: Roger Willcocks <roger@xxxxxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 12:36:05 +0100
We had a similar problem with direct io here, with 2.6.9; I quote from the Bugzilla: "mkfs.xfs has md-specific code (!) that looks at the raid flavour to figure stripe parameters, alignment requireme
/archives/xfs/2010-08/msg00126.html (8,912 bytes)

7. Re: Alignment size? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 21:39:15 +1000
.... If the software was as old as the machine, then that's the likely reason. The old md raid5 implementation did not handle sub-page size aligned IO very well - a change of IO alignment would cause
/archives/xfs/2010-08/msg00127.html (10,367 bytes)

8. Re: Alignment size? (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 11:15:39 -0400
That workaround is still in latests mkfs.xfs if you build against the internal libdisk instead of libblkid. And that's the case at least for Debian, and probably a few other distributions as well.
/archives/xfs/2010-08/msg00135.html (8,351 bytes)

9. Re: Alignment size? (score: 1)
Author: Michael Tokarev <mjt@xxxxxxxxxx>
Date: Tue, 17 Aug 2010 04:18:28 +0400
[] Um. It appears that mkfs.xfs ignores -s size=512 on this raid5 array, and silently creates a filesystem with 4096 sector size, regardless of various -s size=nn and -s log=mm options. This is xfspr
/archives/xfs/2010-08/msg00168.html (9,423 bytes)

10. Re: Alignment size? (score: 1)
Author: Michael Tokarev <mjt@xxxxxxxxxx>
Date: Tue, 17 Aug 2010 04:30:47 +0400
Debian builds it with internal blkid. Rebuilding it with libblkid fixes that. Thanks! /mjt
/archives/xfs/2010-08/msg00169.html (9,303 bytes)

11. Re: Alignment size? (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 17 Aug 2010 10:31:16 +1000
IIRC, the current debian xfsprogs package is still being built with the old detection library. If you install libblkid and build xfsprogs yourself, it should use the newer detection code and behave a
/archives/xfs/2010-08/msg00170.html (9,518 bytes)


This search system is powered by Namazu