All of lore.kernel.org
 help / color / mirror / Atom feed
* Consider these for the XFS FAQ wiki
@ 2017-02-22 11:55 Vaibhaw Pandey
  2017-02-22 13:00 ` Carlos Maiolino
  2017-02-22 13:41 ` Eric Sandeen
  0 siblings, 2 replies; 6+ messages in thread
From: Vaibhaw Pandey @ 2017-02-22 11:55 UTC (permalink / raw)
  To: linux-xfs

Hey,

I had recently run into the ext4 auto_da_alloc delayed allocation type
behavior with XFS i.e. replace by rename leaving an empty file behind.
It took me forever to debug it cause I couldn't find answers to some
simple questions right away.

You guys are the experts but I would like to suggest adding some
questions (& answers) to the XFS FAQ doc for the clueless folks like
me.

I would suggest the following questions:

0. Does XFS support a mount option equivalent to ext4's auto_da_alloc?
i.e. Does XFS have the workarounds to support the replace by truncate
and replace by rename?
Ans:
Answered exactly in http://oss.sgi.com/archives/xfs/2015-12/msg00553.html

1. Does XFS support a mount option equivalent to ext4's commit? i.e.
How do I control how often does XFS sync to disk? Or Does XFS never
sync to disk until a sync/fsync is called?

Ans:
Answered here: http://article.gmane.org/gmane.comp.file-systems.xfs.general/53376
Reproducing from source:
<snip>
By and large, buffered IO in a filesystem is flushed out by the vm,
due to either age or memory pressure.  The filesystem then responds
to these requests by the VM, writing data as requested.

You can read all about it in
https://www.kernel.org/doc/Documentation/sysctl/vm.txt See
dirty_expire_centisecs and dirty_writeback_centisecs - flushers wake
up every 30s and push on data more than 5s old, by default.
</snip>

2. What is the maximum size of the XFS journal?
Ans: Not sure. But this is the closest answer I could find:
https://serverfault.com/questions/367973/xfs-maximum-log-size-sw-raid-10-mdadm-sles-11-sp1
I could read through the code and find a better answer in case you
folks wouldn't have the time.


Lemme know what you think.

Thanks,
Vaibhaw

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Consider these for the XFS FAQ wiki
  2017-02-22 11:55 Consider these for the XFS FAQ wiki Vaibhaw Pandey
@ 2017-02-22 13:00 ` Carlos Maiolino
  2017-02-22 13:09   ` Vaibhaw Pandey
  2017-02-22 13:41 ` Eric Sandeen
  1 sibling, 1 reply; 6+ messages in thread
From: Carlos Maiolino @ 2017-02-22 13:00 UTC (permalink / raw)
  To: Vaibhaw Pandey; +Cc: linux-xfs

Hello,

> I would suggest the following questions:
> 
> 0. Does XFS support a mount option equivalent to ext4's auto_da_alloc?
> i.e. Does XFS have the workarounds to support the replace by truncate
> and replace by rename?
> Ans:
> Answered exactly in http://oss.sgi.com/archives/xfs/2015-12/msg00553.html
> 
> 1. Does XFS support a mount option equivalent to ext4's commit? i.e.
> How do I control how often does XFS sync to disk? Or Does XFS never
> sync to disk until a sync/fsync is called?
> 
> Ans:
> Answered here: http://article.gmane.org/gmane.comp.file-systems.xfs.general/53376
> Reproducing from source:
> <snip>
> By and large, buffered IO in a filesystem is flushed out by the vm,
> due to either age or memory pressure.  The filesystem then responds
> to these requests by the VM, writing data as requested.
> 
> You can read all about it in
> https://www.kernel.org/doc/Documentation/sysctl/vm.txt See
> dirty_expire_centisecs and dirty_writeback_centisecs - flushers wake
> up every 30s and push on data more than 5s old, by default.
> </snip>

Comparing XFS with EXT4 is not really the goal of xfs.org, and adding things
such as: ext4 do/don't do this, will just feed the filesystem war that
happens so often over internet, and most of us around here are tired of that. It
would just be another source (and official) of information  to feed such hot
and pointless discussions about it, I've seen even the simplest differences
being used as fuel for crappy discussions.

Filesystems have different features and handle issues in different ways, in XFS
for example, there is no mount option to fix the sync-on-close-after-truncate,
such behavior is enforced, as mentioned in the thread pointed by you above,
IMHO, FAQ is not a place for bug fixes history, git log does that.

I wouldn't object to have some information about sync-after-rename, but it still
is some extra fuel for such discussions (it it has already been before).

Regarding the ext4's 'commit' option, as Eric said in the thread, it's VM
responsibility to request a flush to the filesystem, and this, to act as
requested, I wouldn't object to have something like: "xfs flushes buffered IO as
requested by the VM", but, still, it's buffered IO design, and XFS has no "for a
commit every X seconds" optiosn, so, still sounds pointless to me to have it in
a FAQ.

Anyway, I am not the xfs.org maintainer, and this is just my opinion anyway :)
Everytime somebody says something about posting a filesystem comparison, my eyes
burns :)
> 
> 2. What is the maximum size of the XFS journal?
> Ans: Not sure. But this is the closest answer I could find:
> https://serverfault.com/questions/367973/xfs-maximum-log-size-sw-raid-10-mdadm-sles-11-sp1

This should go to mkfs.xfs manpage also :)

Cheers.

-- 
Carlos

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Consider these for the XFS FAQ wiki
  2017-02-22 13:00 ` Carlos Maiolino
@ 2017-02-22 13:09   ` Vaibhaw Pandey
  0 siblings, 0 replies; 6+ messages in thread
From: Vaibhaw Pandey @ 2017-02-22 13:09 UTC (permalink / raw)
  To: Vaibhaw Pandey, linux-xfs

Carlos,

> Comparing XFS with EXT4 is not really the goal of xfs.org, and adding things
> such as: ext4 do/don't do this, will just feed the filesystem war that
> happens so often over internet, and most of us around here are tired of that. It
> would just be another source (and official) of information  to feed such hot
> and pointless discussions about it, I've seen even the simplest differences
> being used as fuel for crappy discussions.

I should have probably phrased the questions better then. :) I do not
much care about ext4 but wanted that general XFS behavior (journal
size, replace-by-rename) and design choices (e.g. sync rate) that
should be available for folks to find easily and authoritatively so
that they don't spend too much time finding it. You folks, obviously,
are the best judge.

Thanks,
Vaibhaw


On Wed, Feb 22, 2017 at 6:30 PM, Carlos Maiolino <cmaiolino@redhat.com> wrote:
> Hello,
>
>> I would suggest the following questions:
>>
>> 0. Does XFS support a mount option equivalent to ext4's auto_da_alloc?
>> i.e. Does XFS have the workarounds to support the replace by truncate
>> and replace by rename?
>> Ans:
>> Answered exactly in http://oss.sgi.com/archives/xfs/2015-12/msg00553.html
>>
>> 1. Does XFS support a mount option equivalent to ext4's commit? i.e.
>> How do I control how often does XFS sync to disk? Or Does XFS never
>> sync to disk until a sync/fsync is called?
>>
>> Ans:
>> Answered here: http://article.gmane.org/gmane.comp.file-systems.xfs.general/53376
>> Reproducing from source:
>> <snip>
>> By and large, buffered IO in a filesystem is flushed out by the vm,
>> due to either age or memory pressure.  The filesystem then responds
>> to these requests by the VM, writing data as requested.
>>
>> You can read all about it in
>> https://www.kernel.org/doc/Documentation/sysctl/vm.txt See
>> dirty_expire_centisecs and dirty_writeback_centisecs - flushers wake
>> up every 30s and push on data more than 5s old, by default.
>> </snip>
>
> Comparing XFS with EXT4 is not really the goal of xfs.org, and adding things
> such as: ext4 do/don't do this, will just feed the filesystem war that
> happens so often over internet, and most of us around here are tired of that. It
> would just be another source (and official) of information  to feed such hot
> and pointless discussions about it, I've seen even the simplest differences
> being used as fuel for crappy discussions.
>
> Filesystems have different features and handle issues in different ways, in XFS
> for example, there is no mount option to fix the sync-on-close-after-truncate,
> such behavior is enforced, as mentioned in the thread pointed by you above,
> IMHO, FAQ is not a place for bug fixes history, git log does that.
>
> I wouldn't object to have some information about sync-after-rename, but it still
> is some extra fuel for such discussions (it it has already been before).
>
> Regarding the ext4's 'commit' option, as Eric said in the thread, it's VM
> responsibility to request a flush to the filesystem, and this, to act as
> requested, I wouldn't object to have something like: "xfs flushes buffered IO as
> requested by the VM", but, still, it's buffered IO design, and XFS has no "for a
> commit every X seconds" optiosn, so, still sounds pointless to me to have it in
> a FAQ.
>
> Anyway, I am not the xfs.org maintainer, and this is just my opinion anyway :)
> Everytime somebody says something about posting a filesystem comparison, my eyes
> burns :)
>>
>> 2. What is the maximum size of the XFS journal?
>> Ans: Not sure. But this is the closest answer I could find:
>> https://serverfault.com/questions/367973/xfs-maximum-log-size-sw-raid-10-mdadm-sles-11-sp1
>
> This should go to mkfs.xfs manpage also :)
>
> Cheers.
>
> --
> Carlos

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Consider these for the XFS FAQ wiki
  2017-02-22 11:55 Consider these for the XFS FAQ wiki Vaibhaw Pandey
  2017-02-22 13:00 ` Carlos Maiolino
@ 2017-02-22 13:41 ` Eric Sandeen
  2017-02-22 14:52   ` Vaibhaw Pandey
  1 sibling, 1 reply; 6+ messages in thread
From: Eric Sandeen @ 2017-02-22 13:41 UTC (permalink / raw)
  To: Vaibhaw Pandey, linux-xfs

On 2/22/17 5:55 AM, Vaibhaw Pandey wrote:
> Hey,
> 
> I had recently run into the ext4 auto_da_alloc delayed allocation type
> behavior with XFS i.e. replace by rename leaving an empty file behind.
> It took me forever to debug it cause I couldn't find answers to some
> simple questions right away.

So I'm curious - what happened, and how did you resolve it?

> You guys are the experts but I would like to suggest adding some
> questions (& answers) to the XFS FAQ doc for the clueless folks like
> me.
> 
> I would suggest the following questions:
> 
> 0. Does XFS support a mount option equivalent to ext4's auto_da_alloc?
> i.e. Does XFS have the workarounds to support the replace by truncate
> and replace by rename?
> Ans:
> Answered exactly in http://oss.sgi.com/archives/xfs/2015-12/msg00553.html

http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F'
alludes to this, but I suppose a better explanation of the existing
heuristic might be nice for those who want the details.  The "binary NULLs"
thing is ancient history.

I agree with Carlos that direct comparisons to other filesystems are
less useful, if nothing else because other filesystems may change.

Documenting what XFS does should be the goal of the FAQ.
 
> 1. Does XFS support a mount option equivalent to ext4's commit? i.e.
> How do I control how often does XFS sync to disk? Or Does XFS never
> sync to disk until a sync/fsync is called?

ext4's commit= doesn't control how often it "syncs to disk", exactly.
(that's a bit vague).

It controls the journal commit time, which may or may not (depending on
other options) control data vs. metadata, etc.  Again, we'd need to
document ext4 in the faq before we started making comparisons to it.  :)

> Ans:
> Answered here: http://article.gmane.org/gmane.comp.file-systems.xfs.general/53376
> Reproducing from source:
> <snip>
> By and large, buffered IO in a filesystem is flushed out by the vm,
> due to either age or memory pressure.  The filesystem then responds
> to these requests by the VM, writing data as requested.

So that's about dirty data flushing, whereas ext4's commit= is more related
to metadata flushing, which may or may not lead to data flushing for some files.
We do document a sysctl:

  fs.xfs.xfssyncd_centisecs     (Min: 100  Default: 3000  Max: 720000)
        The interval at which the filesystem flushes metadata
        out to disk and runs internal cache cleanup routines.

which is different from:

> You can read all about it in
> https://www.kernel.org/doc/Documentation/sysctl/vm.txt See
> dirty_expire_centisecs and dirty_writeback_centisecs - flushers wake
> up every 30s and push on data more than 5s old, by default.
> </snip>

which controls data flushing.  Some of this is filesystems 101; some of
it is specific to xfs...

> 2. What is the maximum size of the XFS journal?
> Ans: Not sure. But this is the closest answer I could find:
> https://serverfault.com/questions/367973/xfs-maximum-log-size-sw-raid-10-mdadm-sles-11-sp1
> I could read through the code and find a better answer in case you
> folks wouldn't have the time.

As you can see from the URL there, the answer is "it's complicated"
and depends on filesystem geometry.  I think it's probably best answered by:

http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E

;) IOWs, why were you messing with the log size in the first place?  :)

-Eric



> 
> Lemme know what you think.
> 
> Thanks,
> Vaibhaw
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Consider these for the XFS FAQ wiki
  2017-02-22 13:41 ` Eric Sandeen
@ 2017-02-22 14:52   ` Vaibhaw Pandey
  2017-02-22 15:12     ` Eric Sandeen
  0 siblings, 1 reply; 6+ messages in thread
From: Vaibhaw Pandey @ 2017-02-22 14:52 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: linux-xfs

Thanks for replying Eric.

> So I'm curious - what happened, and how did you resolve it?
Nothing really. The application in question is the Redis key value
store. Reading through it's code is how I began to suspect rename as
the potential problem. It does a fopen/write/fsync/rename sequence. I
mailed Antirez (Redis's primary author) about it and meanwhile added a
sync call in my code. :)

> I agree with Carlos that direct comparisons to other filesystems are
> less useful, if nothing else because other filesystems may change.
As I said, I probably shouldn't have framed the questions like that.
But, IMHO, those are valid inquiries that people would make about XFS,
even when not comparing it with filesystems they are familiar with. I
was only trying to suggest what could be useful for other developers
looking to understand enough XFS work with it confidently. The current
XFS FAQ does seem to have gaps IMO. But you guys would know best on
what should be documented. :)

> which controls data flushing.  Some of this is filesystems 101; some of
> it is specific to xfs...

That is a rather important difference, thanks for pointing it out!
Again, something that should be added to the FAQ. :)

> ;) IOWs, why were you messing with the log size in the first place?  :)
I wasn't at all :) We are a Database-as-a-Service startup and are
looking to start deploying MongoDB on XFS for better performance. &
understanding the sizing requirements and some level of internals is
important for us.

On Wed, Feb 22, 2017 at 7:11 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> On 2/22/17 5:55 AM, Vaibhaw Pandey wrote:
>> Hey,
>>
>> I had recently run into the ext4 auto_da_alloc delayed allocation type
>> behavior with XFS i.e. replace by rename leaving an empty file behind.
>> It took me forever to debug it cause I couldn't find answers to some
>> simple questions right away.
>
> So I'm curious - what happened, and how did you resolve it?
>
>> You guys are the experts but I would like to suggest adding some
>> questions (& answers) to the XFS FAQ doc for the clueless folks like
>> me.
>>
>> I would suggest the following questions:
>>
>> 0. Does XFS support a mount option equivalent to ext4's auto_da_alloc?
>> i.e. Does XFS have the workarounds to support the replace by truncate
>> and replace by rename?
>> Ans:
>> Answered exactly in http://oss.sgi.com/archives/xfs/2015-12/msg00553.html
>
> http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F'
> alludes to this, but I suppose a better explanation of the existing
> heuristic might be nice for those who want the details.  The "binary NULLs"
> thing is ancient history.
>
> I agree with Carlos that direct comparisons to other filesystems are
> less useful, if nothing else because other filesystems may change.
>
> Documenting what XFS does should be the goal of the FAQ.
>
>> 1. Does XFS support a mount option equivalent to ext4's commit? i.e.
>> How do I control how often does XFS sync to disk? Or Does XFS never
>> sync to disk until a sync/fsync is called?
>
> ext4's commit= doesn't control how often it "syncs to disk", exactly.
> (that's a bit vague).
>
> It controls the journal commit time, which may or may not (depending on
> other options) control data vs. metadata, etc.  Again, we'd need to
> document ext4 in the faq before we started making comparisons to it.  :)
>
>> Ans:
>> Answered here: http://article.gmane.org/gmane.comp.file-systems.xfs.general/53376
>> Reproducing from source:
>> <snip>
>> By and large, buffered IO in a filesystem is flushed out by the vm,
>> due to either age or memory pressure.  The filesystem then responds
>> to these requests by the VM, writing data as requested.
>
> So that's about dirty data flushing, whereas ext4's commit= is more related
> to metadata flushing, which may or may not lead to data flushing for some files.
> We do document a sysctl:
>
>   fs.xfs.xfssyncd_centisecs     (Min: 100  Default: 3000  Max: 720000)
>         The interval at which the filesystem flushes metadata
>         out to disk and runs internal cache cleanup routines.
>
> which is different from:
>
>> You can read all about it in
>> https://www.kernel.org/doc/Documentation/sysctl/vm.txt See
>> dirty_expire_centisecs and dirty_writeback_centisecs - flushers wake
>> up every 30s and push on data more than 5s old, by default.
>> </snip>
>
> which controls data flushing.  Some of this is filesystems 101; some of
> it is specific to xfs...
>
>> 2. What is the maximum size of the XFS journal?
>> Ans: Not sure. But this is the closest answer I could find:
>> https://serverfault.com/questions/367973/xfs-maximum-log-size-sw-raid-10-mdadm-sles-11-sp1
>> I could read through the code and find a better answer in case you
>> folks wouldn't have the time.
>
> As you can see from the URL there, the answer is "it's complicated"
> and depends on filesystem geometry.  I think it's probably best answered by:
>
> http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E
>
> ;) IOWs, why were you messing with the log size in the first place?  :)
>
> -Eric
>
>
>
>>
>> Lemme know what you think.
>>
>> Thanks,
>> Vaibhaw
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Consider these for the XFS FAQ wiki
  2017-02-22 14:52   ` Vaibhaw Pandey
@ 2017-02-22 15:12     ` Eric Sandeen
  0 siblings, 0 replies; 6+ messages in thread
From: Eric Sandeen @ 2017-02-22 15:12 UTC (permalink / raw)
  To: Vaibhaw Pandey; +Cc: linux-xfs

On 2/22/17 8:52 AM, Vaibhaw Pandey wrote:
> Thanks for replying Eric.
> 
>> So I'm curious - what happened, and how did you resolve it?
> Nothing really. The application in question is the Redis key value
> store. Reading through it's code is how I began to suspect rename as
> the potential problem. It does a fopen/write/fsync/rename sequence. I
> mailed Antirez (Redis's primary author) about it and meanwhile added a
> sync call in my code. :)

ok, cool.  Good answer!

>> I agree with Carlos that direct comparisons to other filesystems are
>> less useful, if nothing else because other filesystems may change.
> As I said, I probably shouldn't have framed the questions like that.
> But, IMHO, those are valid inquiries that people would make about XFS,
> even when not comparing it with filesystems they are familiar with. I
> was only trying to suggest what could be useful for other developers
> looking to understand enough XFS work with it confidently. The current
> XFS FAQ does seem to have gaps IMO. But you guys would know best on
> what should be documented. :)

Well, don't get me wrong.  If there are gaps in FAQ, let's fix
them.  And it's a wiki, so as long as it's functioning correctly (?),
then /you/ can fix them!  :)

But we do want to keep the style clean and consistent, and keep it
accurate and factual, and limit it to actual FAQs.

If you'd like to put together proposed new entries and run them by the
list for critique, that'd be great.

>> which controls data flushing.  Some of this is filesystems 101; some of
>> it is specific to xfs...
> 
> That is a rather important difference, thanks for pointing it out!
> Again, something that should be added to the FAQ. :)

I just don't want to go too far into "document the world" in the faq.
Some things like kernel/vfs flushing behavior, which is not xfs-specific,
probably doesn't belong there.

And tunables which should almost never be tuned without a deep
understanding of a specific workload's performance probably don't
belong in the faq either.

There is a strong tendency to turn knobs without really understanding
what they do; highlighting, say, the xfssyncd_centisecs sysctl in the
faq will probably lead to people fiddling with that knob without real
understanding and without good reason.

Or, to put it another way, "what is xfssyncd_centisecs?" is not actually
a Frequently Asked Question; it is a low-level behavior control which
few people will need to touch.

>> ;) IOWs, why were you messing with the log size in the first place?  :)
> I wasn't at all :) We are a Database-as-a-Service startup and are
> looking to start deploying MongoDB on XFS for better performance. &
> understanding the sizing requirements and some level of internals is
> important for us.

I guess my point was: before documenting max log size, we'd document
"why would I want a larger than default log?"  And given that the answer
is almost always "you don't; use the defaults" (tweaking something like
the log size would almost always be the result of fairly low level perf
investigation, not a general suggestion in the faq), we probably don't
need to address log size in the FAQ at all.

Anyway - if there are FAQs you feel are not present in the FAQ list, feel
free to send proposals through the list, and edit the wiki as appropriate.

Thanks!
-Eric

> On Wed, Feb 22, 2017 at 7:11 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
>> On 2/22/17 5:55 AM, Vaibhaw Pandey wrote:
>>> Hey,
>>>
>>> I had recently run into the ext4 auto_da_alloc delayed allocation type
>>> behavior with XFS i.e. replace by rename leaving an empty file behind.
>>> It took me forever to debug it cause I couldn't find answers to some
>>> simple questions right away.
>>
>> So I'm curious - what happened, and how did you resolve it?
>>
>>> You guys are the experts but I would like to suggest adding some
>>> questions (& answers) to the XFS FAQ doc for the clueless folks like
>>> me.
>>>
>>> I would suggest the following questions:
>>>
>>> 0. Does XFS support a mount option equivalent to ext4's auto_da_alloc?
>>> i.e. Does XFS have the workarounds to support the replace by truncate
>>> and replace by rename?
>>> Ans:
>>> Answered exactly in http://oss.sgi.com/archives/xfs/2015-12/msg00553.html
>>
>> http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F'
>> alludes to this, but I suppose a better explanation of the existing
>> heuristic might be nice for those who want the details.  The "binary NULLs"
>> thing is ancient history.
>>
>> I agree with Carlos that direct comparisons to other filesystems are
>> less useful, if nothing else because other filesystems may change.
>>
>> Documenting what XFS does should be the goal of the FAQ.
>>
>>> 1. Does XFS support a mount option equivalent to ext4's commit? i.e.
>>> How do I control how often does XFS sync to disk? Or Does XFS never
>>> sync to disk until a sync/fsync is called?
>>
>> ext4's commit= doesn't control how often it "syncs to disk", exactly.
>> (that's a bit vague).
>>
>> It controls the journal commit time, which may or may not (depending on
>> other options) control data vs. metadata, etc.  Again, we'd need to
>> document ext4 in the faq before we started making comparisons to it.  :)
>>
>>> Ans:
>>> Answered here: http://article.gmane.org/gmane.comp.file-systems.xfs.general/53376
>>> Reproducing from source:
>>> <snip>
>>> By and large, buffered IO in a filesystem is flushed out by the vm,
>>> due to either age or memory pressure.  The filesystem then responds
>>> to these requests by the VM, writing data as requested.
>>
>> So that's about dirty data flushing, whereas ext4's commit= is more related
>> to metadata flushing, which may or may not lead to data flushing for some files.
>> We do document a sysctl:
>>
>>   fs.xfs.xfssyncd_centisecs     (Min: 100  Default: 3000  Max: 720000)
>>         The interval at which the filesystem flushes metadata
>>         out to disk and runs internal cache cleanup routines.
>>
>> which is different from:
>>
>>> You can read all about it in
>>> https://www.kernel.org/doc/Documentation/sysctl/vm.txt See
>>> dirty_expire_centisecs and dirty_writeback_centisecs - flushers wake
>>> up every 30s and push on data more than 5s old, by default.
>>> </snip>
>>
>> which controls data flushing.  Some of this is filesystems 101; some of
>> it is specific to xfs...
>>
>>> 2. What is the maximum size of the XFS journal?
>>> Ans: Not sure. But this is the closest answer I could find:
>>> https://serverfault.com/questions/367973/xfs-maximum-log-size-sw-raid-10-mdadm-sles-11-sp1
>>> I could read through the code and find a better answer in case you
>>> folks wouldn't have the time.
>>
>> As you can see from the URL there, the answer is "it's complicated"
>> and depends on filesystem geometry.  I think it's probably best answered by:
>>
>> http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E
>>
>> ;) IOWs, why were you messing with the log size in the first place?  :)
>>
>> -Eric
>>
>>
>>
>>>
>>> Lemme know what you think.
>>>
>>> Thanks,
>>> Vaibhaw
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-02-22 15:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-22 11:55 Consider these for the XFS FAQ wiki Vaibhaw Pandey
2017-02-22 13:00 ` Carlos Maiolino
2017-02-22 13:09   ` Vaibhaw Pandey
2017-02-22 13:41 ` Eric Sandeen
2017-02-22 14:52   ` Vaibhaw Pandey
2017-02-22 15:12     ` Eric Sandeen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.