Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Feb 2016 10:54:11 -0800
From:      Maxim Sobolev <sobomax@sippysoft.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-fs@freebsd.org, Kirk McKusick <mckusick@mckusick.com>
Subject:   Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA)
Message-ID:  <CAH7qZftDXKr3wFyvaByYy%2BOOT9j2Rmj4832JPpTqx7_YrfL3ew@mail.gmail.com>
In-Reply-To: <CAH7qZfvXewt7g5Ei_W21AsC=F%2BYrFe3-YRXrn6eNDbqsRdFRAQ@mail.gmail.com>
References:  <CAH7qZfuZNZ%2BJDPC4D1sjXj2tFxZKBiYVyTp-Y3UUUoq9er%2BWYQ@mail.gmail.com> <20160201165648.GM91220@kib.kiev.ua> <CAH7qZfvcpBo%2BvDho4GeNYWh6N83sebUi-DSG9--T%2BnxQiLhJ1A@mail.gmail.com> <20160201182257.GN91220@kib.kiev.ua> <CAH7qZftsv_0ersqexJ0fTnSQexe4WvpMLnF6X9bj_wX6q9Ewfw@mail.gmail.com> <20160201194014.GQ91220@kib.kiev.ua> <CAH7qZfufYKYD%2BmY8d2wcx3k1kG9CTRXBqXabtJ2p-RKU7uCPfw@mail.gmail.com> <CAH7qZfuzzba8bstboT1R7oE6Qv-9BHgLj=qRd7KN8KvUBzexxw@mail.gmail.com> <20160202132556.GV91220@kib.kiev.ua> <CAH7qZfvXewt7g5Ei_W21AsC=F%2BYrFe3-YRXrn6eNDbqsRdFRAQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
P.S.  "hole = lseek(fd, 0, SEEK_HOLE)" is superfluous there.

On Tue, Feb 2, 2016 at 10:51 AM, Maxim Sobolev <sobomax@sippysoft.com>
wrote:

> Here it is, works on UFS no problems here.
> ----
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> int main(void)
> {
>     char tempname[] = "/tmp/temp.XXXXXX";
>     char *fname;
>     int fd, exval;
>     off_t hole, data;
>
>     fname = mktemp(tempname);
>     if (fname == NULL) {
>         exit (1);
>     }
>     fd = open(fname, O_WRONLY | O_CREAT | O_TRUNC, DEFFILEMODE);
>     if (fd == -1) {
>         exit (1);
>     }
>     if (ftruncate(fd, 1024 * 128) < 0) {
>         exit (1);
>     }
>     hole = lseek(fd, 0, SEEK_HOLE);
>     data = lseek(fd, 0, SEEK_DATA);
>     if (ftruncate(fd, data) < 0) {
>         exit (1);
>     }
>     printf("%s: %jd %jd\n", fname, (intmax_t)hole, (intmax_t)data);
>     exval = 0;
> cleanup:
>     close(fd);
>     exit (exval);
> }
> ----
>
> On Tue, Feb 2, 2016 at 5:25 AM, Konstantin Belousov <kostikbel@gmail.com>
> wrote:
>
>> On Mon, Feb 01, 2016 at 09:17:00PM -0800, Maxim Sobolev wrote:
>> > WRT the:
>> >
>> > > There is no 'hole-only' files on UFS, the last byte in the UFS file
>> must
>> > > be populated, either by allocated fragment if the last byte is in the
>> > > direct blocks range, or by the full block if in the indirect range.
>> >
>> > Ideed, the UFS resists putting a hole at the end of the file, yet, it's
>> > possible to arrange hole-only situation by first truncating an empty
>> file
>> > to some size that is greater than the target hole size, so that you get
>> > hole of the desired size following by the bit of data, and then
>> truncating
>> > the resulting file back to the offset where the data starts:
>> >
>> > -----
>> >     fd = open(fname, O_WRONLY | O_CREAT | O_TRUNC, DEFFILEMODE);
>> >     if (fd == -1) {
>> >         exit (1);
>> >     }
>> >     if (ftruncate(fd, 1024 * 128) < 0) {
>> >         exit (1);
>> >     }
>> >     data = lseek(fd, 0, SEEK_DATA);
>> >     if (data >= 0 && ftruncate(fd, data) < 0) {
>> >         exit (1);
>> >     }
>> > -----
>> > [sobomax@rtpdev ~/projects/freebsd11/usr.bin/lsholes]$ ./lsholes
>> > /tmp/temp.MgoPPo
>> > Type Start   End  Size
>> > HOLE     0 98303 98304
>> >
>> > Total HOLE: 98304 (100.00%)
>> > Total DATA: 0 (0.00%)
>> > [sobomax@rtpdev ~/projects/freebsd11/usr.bin/lsholes]$ ls -l
>> > /tmp/temp.MgoPPo
>> > -rw-r--r--  1 sobomax  wheel  98304 Feb  1 21:06 /tmp/temp.MgoPPo
>> Is this on UFS ?
>>
>> Please provide me with the program to re-create it, if on UFS.
>> At least fsck is not ready for files with holes at tail, and several
>> kernel code fragments expect last byte to be allocated.  I once had
>> a patch to allow hole at tail for UFS, but I did not moved it to the
>> committable state.
>>
>> > -----
>> >
>> > I don't know if operating on that file would result in some data
>> > corruption, but I also seem have no issues creating hole-only files on
>> ZFS
>> > using my fallocate(2) syscall.
>>
>>
>
>
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales@sippysoft.com
> Skype: SippySoft
>



-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sales@sippysoft.com
Skype: SippySoft



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAH7qZftDXKr3wFyvaByYy%2BOOT9j2Rmj4832JPpTqx7_YrfL3ew>