[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56D9C882.3040808@intel.com>
Date: Fri, 4 Mar 2016 09:40:18 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>,
linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Hugh Dickins <hughd@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Christoph Lameter <cl@...two.org>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Jerome Marchand <jmarchan@...hat.com>,
Yang Shi <yang.shi@...aro.org>,
Sasha Levin <sasha.levin@...cle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE
On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote:
> On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov wrote:
>> Truncate and punch hole that only cover part of THP range is implemented
>> by zero out this part of THP.
>>
>> This have visible effect on fallocate(FALLOC_FL_PUNCH_HOLE) behaviour.
>> As we don't really create hole in this case, lseek(SEEK_HOLE) may have
>> inconsistent results depending what pages happened to be allocated.
>> Not sure if it should be considered ABI break or not.
>
> Looks like this shouldn't be a problem. man 2 fallocate:
>
> Within the specified range, partial filesystem blocks are zeroed,
> and whole filesystem blocks are removed from the file. After a
> successful call, subsequent reads from this range will return
> zeroes.
>
> It means we effectively have 2M filesystem block size.
The question is still whether this will case problems for apps.
Isn't 2MB a quote unusual block size? Wouldn't some files on a tmpfs
filesystem act like they have a 2M blocksize and others like they have
4k? Would that confuse apps?
Powered by blists - more mailing lists