Date: Tue, 2 Feb 2016 10:51:19 -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: <CAH7qZfvXewt7g5Ei_W21AsC=F%2BYrFe3-YRXrn6eNDbqsRdFRAQ@mail.gmail.com> In-Reply-To: <20160202132556.GV91220@kib.kiev.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAH7qZfvXewt7g5Ei_W21AsC=F%2BYrFe3-YRXrn6eNDbqsRdFRAQ>