[PATCH 2/2]xfs_io man page

[PATCH 2/2]xfs_io man page

[Utako Kusaka]

Hi,

This patch adds offset and length parameter to the man page for 
pread, pwrite, mread and mwrite command in xfs_io(8).
I guess this is useful for testers.
What do you think of it?

Signed-off-by: Utako Kusaka <utako@tnes.nec.co.jp>
---

--- xfsprogs-2.8.15-orgn/man/man8/xfs_io.8	2006-07-04 20:57:05.000000000 +0900
+++ xfsprogs-2.8.15/man/man8/xfs_io.8	2006-11-16 15:55:34.566928372 +0900
@@ -99,7 +99,7 @@ Closes the current open file, marking th
 \f3c\f1
 See the \f3close\f1 command.
 .TP
-\f3pread\f1 [ \f2\-b bsize\f1 ] [ \f2\-v\f1 ]
+\f3pread\f1 [ \f2\-b bsize\f1 ] [ \f2\-v\f1 ] \f2offset\f1 \f2length\f1
 Reads a range of bytes in a specified blocksize from the given offset.
 .br
 The \f3\-b\f1 option can be used to set the blocksize into which the
@@ -112,7 +112,7 @@ by default only the count of bytes actua
 \f3r\f1
 See the \f3pread\f1 command.
 .TP
-\f3pwrite\f1 [ \f2\-i file\f1 ] [ \f2\-d\f1 ] [ \f2\-s skip\f1 ] [ \f2\-b size\f1 ] [ \f2\-S seed\f1 ]
+\f3pwrite\f1 [ \f2\-i file\f1 ] [ \f2\-d\f1 ] [ \f2\-s skip\f1 ] [ \f2\-b size\f1 ] [ \f2\-S seed\f1 ] \f2offset
\f1 \f2length\f1
 Writes a range of bytes in a specified blocksize from the given offset.
 The bytes written can be either a set pattern or read in from another
 file before writing.
@@ -211,7 +211,7 @@ Unmaps the current memory mapping.
 \f3mu\f1
 See the \f3munmap\f1 command.
 .TP
-\f3mread\f1 [ \-\f2frv\f1 ]
+\f3mread\f1 [ \-\f2frv\f1 ] [ \f2offset\f1 \f2length\f1 ]
 Accesses a segment of the current memory mapping, optionally dumping it to
 the standard output stream (with \f2-v\f1 or \f2-f\f1 option) for inspection.
 The accesses are performed sequentially from the start offset by default,
@@ -224,7 +224,7 @@ offsets relative to the start of the map
 \f3mr\f1
 See the \f3mread\f1 command.
 .TP
-\f3mwrite\f1 [ \f2-r\f1 ] [ \f2-S seed\f1 ]
+\f3mwrite\f1 [ \f2-r\f1 ] [ \f2-S seed\f1 ] [ \f2offset\f1 \f2length\f1 ]
 Stores a byte into memory for a range within a mapping.
 The default stored value is 'X', repeated to fill the range specified,
 but this can be changed using the \f2-S\f1 option.

Re: [PATCH 2/2]xfs_io man page

[Nathan Scott]

On Wed, 2006-11-29 at 09:27 +0900, Utako Kusaka wrote:
> Hi,
> 
> This patch adds offset and length parameter to the man page for 
> pread, pwrite, mread and mwrite command in xfs_io(8).
> I guess this is useful for testers.
> What do you think of it?
> 

Looks good to me.

cheers.

-- 
Nathan

inode64 workaround

[Deanan]

Hi,

I've got some systems that I can't change the kernel on (external 
vendor) that
are 32bit but I'm running into the performance problem that is fixed by 
using
inode64. Is there any known way of working around the problem on a 32bit 
kernel?

In our case, the problem occurs as soon as you start to delete files and 
write new ones.

Cheers,

Deanan

Re: inode64 workaround

[David Chatterton]

Deanan,

Would something like the inode rotor help?

  fs.xfs.rotorstep              (Min: 1  Default: 1  Max: 256)

        In "inode32" allocation mode, this option determines how many

        files the allocator attempts to allocate in the same allocation

        group before moving to the next allocation group.  The intent

        is to control the rate at which the allocator moves between

        allocation groups when allocating extents for new files.

David


Deanan wrote:
> 
> Hi,
> 
> I've got some systems that I can't change the kernel on (external
> vendor) that
> are 32bit but I'm running into the performance problem that is fixed by
> using
> inode64. Is there any known way of working around the problem on a 32bit
> kernel?
> 
> In our case, the problem occurs as soon as you start to delete files and
> write new ones.
> 
> Cheers,
> 
> Deanan
> 

-- 
David Chatterton
XFS Engineering Manager
SGI Australia

Re: inode64 workaround

[Deanan]

Hi David,

I'm not sure if it will help but I'd like to try.
Where do you set the rotor?
 BTW< tis particular box is 2.6.9.

Thanks,

Deanan


> Deanan,
>
> Would something like the inode rotor help?
>
>   fs.xfs.rotorstep              (Min: 1  Default: 1  Max: 256)
>
>         In "inode32" allocation mode, this option determines how many
>
>         files the allocator attempts to allocate in the same allocation
>
>         group before moving to the next allocation group.  The intent
>
>         is to control the rate at which the allocator moves between
>
>         allocation groups when allocating extents for new files.
>
> David
>
>
> Deanan wrote:
>   
>> Hi,
>>
>> I've got some systems that I can't change the kernel on (external
>> vendor) that
>> are 32bit but I'm running into the performance problem that is fixed by
>> using
>> inode64. Is there any known way of working around the problem on a 32bit
>> kernel?
>>
>> In our case, the problem occurs as soon as you start to delete files and
>> write new ones.
>>
>> Cheers,
>>
>> Deanan
>>
>>     
>
>   



[[HTML alternate version deleted]]

Re: inode64 workaround

[David Chatterton]

This is a sysctl, see sysctl(8).

It was introduced to XFS in October 2004, I'm not sure if it made 2.6.9.

If this doesn't help a little then I'm unsure why you think that inode64 is
going to solve your problem?

David


Deanan wrote:
> Hi David,
> 
> I'm not sure if it will help but I'd like to try.
> Where do you set the rotor?
>  BTW< tis particular box is 2.6.9.
> 
> Thanks,
> 
> Deanan
> 
> 
>> Deanan,
>>
>> Would something like the inode rotor help?
>>
>>   fs.xfs.rotorstep              (Min: 1  Default: 1  Max: 256)
>>
>>         In "inode32" allocation mode, this option determines how many
>>
>>         files the allocator attempts to allocate in the same allocation
>>
>>         group before moving to the next allocation group.  The intent
>>
>>         is to control the rate at which the allocator moves between
>>
>>         allocation groups when allocating extents for new files.
>>
>> David
>>
>>
>> Deanan wrote:
>>   
>>> Hi,
>>>
>>> I've got some systems that I can't change the kernel on (external
>>> vendor) that
>>> are 32bit but I'm running into the performance problem that is fixed by
>>> using
>>> inode64. Is there any known way of working around the problem on a 32bit
>>> kernel?
>>>
>>> In our case, the problem occurs as soon as you start to delete files and
>>> write new ones.
>>>
>>> Cheers,
>>>
>>> Deanan
>>>
>>>     
>>
>>   
> 

-- 
David Chatterton
XFS Engineering Manager
SGI Australia

Re: inode64 workaround

[Deanan]

Thanks. Unfortunately 2.6.9 doesn't have it. :(

> This is a sysctl, see sysctl(8).
>
> It was introduced to XFS in October 2004, I'm not sure if it made 2.6.9.
>
> If this doesn't help a little then I'm unsure why you think that inode64 is
> going to solve your problem?
>
> David
>   

Re: inode64 workaround

[Eric Sandeen]

Deanan wrote:
> Thanks. Unfortunately 2.6.9 doesn't have it. :(

Is this rhel4?

You could probably pretty easily add the inode rotor code into the xfs 
modules that you're using, if that's the case.

-Eric

>> This is a sysctl, see sysctl(8).
>>
>> It was introduced to XFS in October 2004, I'm not sure if it made 2.6.9.
>>
>> If this doesn't help a little then I'm unsure why you think that 
>> inode64 is
>> going to solve your problem?
>>
>> David
>>   
> 
> 

Re: inode64 workaround

[Deanan]

It's a generic 2.6.9 kernel (AFAIK).
I tried the same setting on a different box with SLES 9 SP3 (2.6.5) 
which does have rotorstep.
With inode64 I can sustain 235+MB/s on the same array test after test.
When I do not mount with inode64, I get the same results as the 32bit 
machine (~100-130MB/s)
Without inode64 plus rotorstep (set to 255), the perfomance improves to 
about 140-160MB/s.

Generally the first test is fast and then drops over the next few tests 
(even writing as few
as 100 16mb files per test).

Thanks,

Deanan

> Deanan wrote:
>> Thanks. Unfortunately 2.6.9 doesn't have it. :(
>
> Is this rhel4?
>
> You could probably pretty easily add the inode rotor code into the xfs 
> modules that you're using, if that's the case.
>
> -Eric
>
>>> This is a sysctl, see sysctl(8).
>>>
>>> It was introduced to XFS in October 2004, I'm not sure if it made 
>>> 2.6.9.
>>>
>>> If this doesn't help a little then I'm unsure why you think that 
>>> inode64 is
>>> going to solve your problem?
>>>
>>> David
>>>   
>>
>>
>
>