I have noticed similarly odd behaviour from softupdates during heavy
IO load, where something is creating lots of little files or
directories and not much else is happening. Using `vmstat 1` I can see
that softupdates isn't very good at evening out the IO rate over time:
there's a roughly sinusoid
"David Schwartz" wrote:
> We're talking about the special case of small root partitions, such that
> softupdates inability to make empty space available quickly can make the
> difference between a major operation's success or failure.
>
> This is almost impossible on a 1.8Gb root part
:> We're talking about the special case of small root partitions, such that
:> softupdates inability to make empty space available quickly can make the
:> difference between a major operation's success or failure.
:>
:> This is almost impossible on a 1.8Gb root partition.
:
:Again why
> We're talking about the special case of small root partitions, such that
> softupdates inability to make empty space available quickly can make the
> difference between a major operation's success or failure.
>
> This is almost impossible on a 1.8Gb root partition.
Again why? Wha
> On Thu, Oct 07, 1999 at 03:15:03PM -0700, David Schwartz wrote:
> > > > There should be fairly few writes to the root partition, so having
> > > An opionion. I use the HP workstation model where my / is
> 1800M. I have
>
> > You are not disagreeing with him, David. You are just talking ab
On Thu, Oct 07, 1999 at 03:15:03PM -0700, David Schwartz wrote:
> > > There should be fairly few writes to the root partition, so having
> > An opionion. I use the HP workstation model where my / is 1800M. I have
> You are not disagreeing with him, David. You are just talking about
>
On 1999-Oct-08 08:13:12 +1000, David O'Brien wrote:
>> >mount(8):
>> > syncAll I/O to the file system should be done synchronously.
>>
>> How detailed should the man page be? If it stated "all file data will
>> be written synchronously, but inodes where the only update is atime
>> and f
> > There should be fairly few writes to the root partition, so having
>
> An opionion. I use the HP workstation model where my / is 1800M. I have
> no use for /var and /usr and find them simply stupid in today's world.
> (except for ISP's where there is cause for a septerate /var).
>
> Lets sti
> >mount(8):
> > syncAll I/O to the file system should be done synchronously.
>
> How detailed should the man page be? If it stated "all file data will
> be written synchronously, but inodes where the only update is atime
> and free block bitmaps are written asynchronously", would that
> There should be fairly few writes to the root partition, so having
An opionion. I use the HP workstation model where my / is 1800M. I have
no use for /var and /usr and find them simply stupid in today's world.
(except for ISP's where there is cause for a septerate /var).
Lets stick to facts.
Maybe the best solution is the following:
- leave "sync" with its current behaviour
- create a sysctl to make it truely synchronous (I was thinking of a new
mount option but thats overkill) and have the documentation for that
sysctl state the performance hit and recommend that the filesystem be
m
On Thu, Oct 07, 1999 at 11:57:26AM +1000, a little birdie told me
that Peter Jeremy remarked
>
> How detailed should the man page be?
Exactly my query in writing this ;>
> If it stated "all file data will
> be written synchronously, but inodes where the only update is atime
> and free block b
On 1999-Oct-07 09:15:42 +1000, Matthew D. Fuller wrote:
>Is this good, bad, ugly, or just inconsistent? On the one hand, you can
>argue that 'sync should be sync should be sync, I don't bloody care, just
>don't do anything async at all', since that's what it's supposed to do:
>mount(8):
> sy
:mount(8):
: syncAll I/O to the file system should be done synchronously.
:
:On the gripping hand, you can say, 'this is an ATIME update, there's no
:way its presence or lack thereof can do anything bad to the filesystem,
:so let it be async since it takes extra work to make it syn
Thank you, this is *EXACTLY* what I was looking for :)
On Thu, Oct 07, 1999 at 08:59:00AM +1000, a little birdie told me
that Peter Jeremy remarked
>
> As far as I can tell, the net effect is that inode access time updates
> will remain async writes into the filesystem.
>
> An easy way to tel
15 matches
Mail list logo
