Re: [RFC][PATCH 0/3] add FALLOC_FL_NO_HIDE_STALE flag in fallocate

[Lukas Czerner]

On Wed, 18 Apr 2012, Zheng Liu wrote:

--snip--

> > > 
> > > I will run more detailed benchmarks to trace this issue.  If I have a
> > > lastest result, I will send a new mail to let you know. :)
> > 
> > Yes, please do. I do not think that in this case simply doing 'time
> > dd' is enough. We need to know what is happening inside the kernel to see
> > what is causing the slowdown. It may very well be that we might be able
> > to fix it, rather than introduce crazy security hole to bypass the
> > problem.
> 
> Sorry, maybe my expression is not clear.  Now we have two problems that
> need to be discussed in this thread.  One is my patch set about adding a
> new fallocate flag, and another is that the result of preallocated case
> with conversion is too slower than the result of the case without
> conversion.
> 
> For new flag, last year we have encountered this problem in our product
> system.  We decide to add this flag to avoid the overhead because our
> application can guarantee to initialize the file before it read data
> from this file.  As I said before, last month on ext4 workshop, we
> discussed this problem and Ted said that the Google has the same problem
> too.  So we think that maybe this flag is useful for other users.  That
> is reason why I send this patch set to mailing list. 
> 
> For benchmark result, that is a simple test.  When I send this patch set
> to mailing list, I think that I need to get some data to compare the
> performance of w/ and w/o this new flag.  I am astonished by the result.
> So, as I said above, the target of my patch set is not to solve this issue.
> 
> I have run a more detailed benchmark and I will post it to mailing list.
> Please review it after I send it.  Any comments are welcomed.

Ok I do understand this, but as other people in the thread already told
you, this is not a proper fix. If you have a performance problem when the
conversion from uninitialized to initialized happens, than the obvious
answer is figure out why and fix it, rather than create crazy workaround
without even properly testing why this is happening.

Regards,
-Lukas

> 
> Regards,
> Zheng

--snip--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/