linux-kernel - Re: [RFC][PATCH 0/3] add FALLOC_FL_NO_HIDE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1204181402550.5310@dhcp-27-109.brq.redhat.com>
Date:	Wed, 18 Apr 2012 14:07:09 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Zheng Liu <gnehzuil.liu@...il.com>
cc:	Lukas Czerner <lczerner@...hat.com>,
	Eric Sandeen <sandeen@...hat.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org, Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [RFC][PATCH 0/3] add FALLOC_FL_NO_HIDE_STALE flag in fallocate

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/