On 2013-05-14, at 0:25, Daniel Phillips
wrote:
> Interesting, Andreas. We don't do anything as heavyweight as
> allocating an inode in this path, just mark the inode dirty (which
> puts it on a list) and set a bit in the inode flags.
The new inode allocation is only needed for the
On 2013-05-14, at 0:25, Daniel Phillips daniel.raymond.phill...@gmail.com
wrote:
Interesting, Andreas. We don't do anything as heavyweight as
allocating an inode in this path, just mark the inode dirty (which
puts it on a list) and set a bit in the inode flags.
The new inode allocation is
Dave Chinner writes:
>> Right. Because tux3 is not implementing fsync() yet. So, I did
>>
>> grep -v Flush /usr/share/dbench/client.txt > client2.txt
>>
>> Why is it important for comparing?
>
> Because nobody could reproduce your results without working that
> out. You didn't disclose
On Fri, May 10, 2013 at 02:47:35PM +0900, OGAWA Hirofumi wrote:
> Dave Chinner writes:
>
> >> tux3:
> >> Operation CountAvgLatMaxLat
> >>
> >> NTCreateX1477980 0.00312.944
> >
> >> ReadX2316653
Interesting, Andreas. We don't do anything as heavyweight as
allocating an inode in this path, just mark the inode dirty (which
puts it on a list) and set a bit in the inode flags.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Interesting, Andreas. We don't do anything as heavyweight as
allocating an inode in this path, just mark the inode dirty (which
puts it on a list) and set a bit in the inode flags.
Regards,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Fri, May 10, 2013 at 02:47:35PM +0900, OGAWA Hirofumi wrote:
Dave Chinner da...@fromorbit.com writes:
tux3:
Operation CountAvgLatMaxLat
NTCreateX1477980 0.00312.944
ReadX2316653
Dave Chinner da...@fromorbit.com writes:
Right. Because tux3 is not implementing fsync() yet. So, I did
grep -v Flush /usr/share/dbench/client.txt client2.txt
Why is it important for comparing?
Because nobody could reproduce your results without working that
out. You didn't
Hi Ted,
You said:
> ...any advantage of decoupling the front/back end
> is nullified, since fsync(2) requires a temporal coupling
After after pondering it for a while, I realized that is not
completely accurate. The reduced delete latency will
allow the dbench process to proceed to the fsync
Hi Ted,
You said:
...any advantage of decoupling the front/back end
is nullified, since fsync(2) requires a temporal coupling
After after pondering it for a while, I realized that is not
completely accurate. The reduced delete latency will
allow the dbench process to proceed to the fsync
On Sat, May 11, 2013 at 11:35 AM, james northrup
wrote:
> also interesting information... Study of 2,047 papers on PubMed finds
> that two-thirds of retracted papers were down to scientific
> misconduct, not error
Could you please be specific about the meaning you intend? Because
innuendo is
(resent as plain text)
On Sat, May 11, 2013 at 2:26 PM, Theodore Ts'o wrote:
> Dropping fsync() does a lot more than "amplify Tux3's advantage in
> delete performace". Since fsync(2) is defined as not returning until
> the data written to the file descriptor is flushed out to stable
> storage
On Fri, May 10, 2013 at 11:12:27PM -0700, Daniel Phillips wrote:
> Hi Dave,
>
> Thanks for the catch - I should indeed have noted that "modified
> dbench" was used for this benchmark, thus amplifying Tux3's advantage
> in delete performance.
Dropping fsync() does a lot more than "amplify Tux3's
also interesting information... Study of 2,047 papers on PubMed finds
that two-thirds of retracted papers were down to scientific
misconduct, not error
On Fri, May 10, 2013 at 11:12 PM, Daniel Phillips
wrote:
> Hi Dave,
>
> Thanks for the catch - I should indeed have noted that "modified
>
Hi Dave,
Thanks for the catch - I should indeed have noted that "modified
dbench" was used for this benchmark, thus amplifying Tux3's advantage
in delete performance. This literary oversight does not make the
results any less interesting: we beat Tmpfs on that particular load.
Beating tmpfs at
Hi Dave,
Thanks for the catch - I should indeed have noted that modified
dbench was used for this benchmark, thus amplifying Tux3's advantage
in delete performance. This literary oversight does not make the
results any less interesting: we beat Tmpfs on that particular load.
Beating tmpfs at
also interesting information... Study of 2,047 papers on PubMed finds
that two-thirds of retracted papers were down to scientific
misconduct, not error
On Fri, May 10, 2013 at 11:12 PM, Daniel Phillips
daniel.raymond.phill...@gmail.com wrote:
Hi Dave,
Thanks for the catch - I should indeed
On Fri, May 10, 2013 at 11:12:27PM -0700, Daniel Phillips wrote:
Hi Dave,
Thanks for the catch - I should indeed have noted that modified
dbench was used for this benchmark, thus amplifying Tux3's advantage
in delete performance.
Dropping fsync() does a lot more than amplify Tux3's
(resent as plain text)
On Sat, May 11, 2013 at 2:26 PM, Theodore Ts'o ty...@mit.edu wrote:
Dropping fsync() does a lot more than amplify Tux3's advantage in
delete performace. Since fsync(2) is defined as not returning until
the data written to the file descriptor is flushed out to stable
On Sat, May 11, 2013 at 11:35 AM, james northrup
northrup.ja...@gmail.com wrote:
also interesting information... Study of 2,047 papers on PubMed finds
that two-thirds of retracted papers were down to scientific
misconduct, not error
Could you please be specific about the meaning you intend?
Dave Chinner writes:
>> tux3:
>> Operation CountAvgLatMaxLat
>>
>> NTCreateX1477980 0.00312.944
>
>> ReadX2316653 0.002 0.499
>> LockX 4812 0.002 0.207
>> UnlockX
Aloha hardcore coders
Thank you very much for working out the facts, Dave.
You proved why I had all the years such a special suspicious feeling by
reading between the lines of the Tux3 e-mails sent to the mailing-list,
which should not mean that I do not like the work around the Tux3 file
On Tue, May 07, 2013 at 04:24:05PM -0700, Daniel Phillips wrote:
> When something sounds to good to be true, it usually is. But not always. Today
> Hirofumi posted some nigh on unbelievable dbench results that show Tux3
> beating tmpfs. To put this in perspective, we normally regard tmpfs as
>
On Tue, May 07, 2013 at 04:24:05PM -0700, Daniel Phillips wrote:
When something sounds to good to be true, it usually is. But not always. Today
Hirofumi posted some nigh on unbelievable dbench results that show Tux3
beating tmpfs. To put this in perspective, we normally regard tmpfs as
Aloha hardcore coders
Thank you very much for working out the facts, Dave.
You proved why I had all the years such a special suspicious feeling by
reading between the lines of the Tux3 e-mails sent to the mailing-list,
which should not mean that I do not like the work around the Tux3 file
Dave Chinner da...@fromorbit.com writes:
tux3:
Operation CountAvgLatMaxLat
NTCreateX1477980 0.00312.944
ReadX2316653 0.002 0.499
LockX 4812 0.002 0.207
UnlockX
When something sounds to good to be true, it usually is. But not always. Today
Hirofumi posted some nigh on unbelievable dbench results that show Tux3
beating tmpfs. To put this in perspective, we normally regard tmpfs as
unbeatable because it is just a thin shim between the standard VFS
When something sounds to good to be true, it usually is. But not always. Today
Hirofumi posted some nigh on unbelievable dbench results that show Tux3
beating tmpfs. To put this in perspective, we normally regard tmpfs as
unbeatable because it is just a thin shim between the standard VFS
28 matches
Mail list logo
