On Sat, 3 May 2014, Michael Kerrisk (man-pages) wrote: > Date: Sat, 03 May 2014 05:07:40 +0200 > From: "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> > To: Lukáš Czerner <lczerner@xxxxxxxxxx> > Cc: mtk.manpages@xxxxxxxxx, linux-man@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2] fallocate.2: Document FALLOC_FL_ZERO_RANGE > > Hi Lukáš > > Ping on the question below... > > Cheers, > > Michael > > > On 04/30/2014 09:47 PM, Michael Kerrisk (man-pages) wrote: > > Lukáš, > > > > On 04/30/2014 04:54 PM, Lukáš Czerner wrote: > >> On Wed, 30 Apr 2014, Michael Kerrisk (man-pages) wrote: > >> > >>> Date: Wed, 30 Apr 2014 16:48:42 +0200 > >>> From: "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> > >>> To: Lukas Czerner <lczerner@xxxxxxxxxx>, linux-man@xxxxxxxxxxxxxxx > >>> Cc: mtk.manpages@xxxxxxxxx > >>> Subject: Re: [PATCH v2] fallocate.2: Document FALLOC_FL_ZERO_RANGE > >>> > >>> Hi Lukas > >>> > >>> On 04/30/2014 04:09 PM, Lukas Czerner wrote: > >>>> FALLOC_FL_ZERO_RANGE was added in Linux 3.14, > >>>> for zeroing ranges in the allocated space in a file. > >>>> > >>>> Signed-off-by: Lukas Czerner <lczerner@xxxxxxxxxx> > >>>> --- > >>>> v2: Rebase and update the description > >>>> > >>>> man2/fallocate.2 | 46 +++++++++++++++++++++++++++++++++++++++++++++- > >>>> 1 file changed, 45 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/man2/fallocate.2 b/man2/fallocate.2 > >>>> index 73c4f12..30f27c3 100644 > >>>> --- a/man2/fallocate.2 > >>>> +++ b/man2/fallocate.2 > >>>> @@ -180,6 +180,48 @@ ext4 (only for extent-based files) > >>>> .\" commit 9eb79482a97152930b113b51dff530aba9e28c8e > >>>> and XFS. > >>>> .\" commit e1d8fb88a64c1f8094b9f6c3b6d2d9e6719c970d > >>>> +.SS Zeroing file space > >>>> +Specifying > >>>> +.BR FALLOC_FL_ZERO_RANGE > >>>> +flag (available since Linux 3.14) in > >>>> +.I mode > >>>> +zeroes space in the byte range starting at > >>>> +.I offset > >>>> +and continuing for > >>>> +.I len > >>>> +bytes. > >>>> +Within the specified range, blocks are preallocated for the regions > >>>> +that span the holes in the file. After a successful call, subsequent > >>>> +reads from this range will return zeroes. > >>>> + > >>>> +Zeroing is done within the file system preferably by converting range into > >>>> +unwritten extents which requires very little IO to be issued mostly for > >>>> +metadata. This means that the range will not be physically zeroed out > >>>> +on the device. > >>> > >>> I just want to confirm my understanding of what's going on here. > >>> FALLOC_FL_ZERO_RANGE is serving at least two purposes: > >>> 1. Future reads from the specified range will return zero. > >>> 2. Blocks (in the form of extents) will be preallocated for the holes > >>> in the range, thus ensuring that the necessary storage space is > >>> allocated for the file. However, those allocated blocks won't actually > >>> be written to. (Metadata trickery will ensure that reads from that > >>> region won't actually touch the blocks; the kernel will simply deliver > >>> back zeroes.) > >>> > >>> Right? > >> > >> Yes, that's exactly right. > > > > Thanks. > > > >>> And a question: does FALLOC_FL_ZERO_RANGE work for non-extent-based > >>> filesystems? If yes, how is FALLOC_FL_ZERO_RANGE implemented? Are the > >>> blocks corresponding to a hole actually allocated and explicitly > >>> written with zeroes? > >> > >> As it is now, FALLOC_FL_ZERO_RANGE does not work on non-extent based > >> files. This is also the case for collapse range and the regular > >> preallocation at least in ext4 case. > > > > Okay -- see my comment below.. > > > >>>> + > >>>> +If the > >>>> +.B FALLOC_FL_KEEP_SIZE > >>>> +flag is specified in > >>>> +.IR mode , > >>>> +the behavior of the call is similar, > >>>> +but the file size will not be changed even if > >>>> +.IR offset + len > >>>> +is greater than the file size. This behaviour is the same as when > >>>> +preallocating space with > >>>> +.B FALLOC_FL_KEEP_SIZE > >>>> +specified. > >>>> + > >>>> +Not all filesystems support > >>>> +.BR FALLOC_FL_ZERO_RANGE ; > >>>> +if a filesystem doesn't support the operation, an error is returned. > >>>> +The operation is supported on at least the following filesystems > >>>> +.IP * 3 > >>>> +XFS (since Linux 2.14) > >>>> +.\" commit 376ba313147b4172f3e8cf620b9fb591f3e8cdfa > >>>> +.IP * > >>>> +ext4 (since Linux 3.14) > >>>> +.\" commit b8a8684502a0fc852afa0056c6bb2a9273f6fcc0 > >>>> + > > > > So for these two cases, XFS and ext4, should we perhaps better say > > > > XFS, for extent based files (since Linux 3.14) XFS does not have non-extent based files. I'll resend. Thanks! -Lukas > > ext4, for extent based files (since Linux 3.14) > > ? > > > > Cheers, > > > > Michael > > > > > >>>> .SH RETURN VALUE > >>>> On success, > >>>> .BR fallocate () > >>>> @@ -243,7 +285,9 @@ no other flags are permitted with > >>>> .B EINVAL > >>>> .I mode > >>>> is > >>>> -.BR FALLOC_FL_COLLAPSE_RANGE , > >>>> +.BR FALLOC_FL_COLLAPSE_RANGE > >>>> +or > >>>> +.BR FALLOC_FL_ZERO_RANGE, > >>>> but the file referred to by > >>>> .I fd > >>>> is not a regular file. > >>>> > >>> > >>> > >>> > >> > > > > > > >
