Date: Mon, 1 Feb 2016 18:56:48 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: freebsd-fs@freebsd.org, Kirk McKusick <mckusick@mckusick.com> Subject: Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) Message-ID: <20160201165648.GM91220@kib.kiev.ua> In-Reply-To: <CAH7qZfuZNZ%2BJDPC4D1sjXj2tFxZKBiYVyTp-Y3UUUoq9er%2BWYQ@mail.gmail.com> References: <CAH7qZfuZNZ%2BJDPC4D1sjXj2tFxZKBiYVyTp-Y3UUUoq9er%2BWYQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 01, 2016 at 07:57:40AM -0800, Maxim Sobolev wrote: > Hi, > > I've noticed that lseek() behaved inconsistently with regards to SEEK_HOLE > and SEEK_DATA operations. The SEEK_HOLE on a data-only file returns st_size > (i.e. EOF + 1), while the SEEK_DATA on a hole-only file returns -1 and sets > errno to ENXIO. The latter seems to be a documented way to indicate that > the file has no more data sections past this point. > > My first idea was that somehow most files has a hole attached to its end to > fill up the FS block, but that does not seem to be a case. Trying to > SEEK_HOLE past the end of any of those data-only files produces an error > (i.e. lseek(fd, st_size, SEEK_HOLE) == -1). > > In short, for some reason I cannot get proper ENXIO from the SEEK_HOLE. > What currently returned implies that there is 1-byte hole attached to each > file past its EOF and that does not smell right. > > All tests are done on UFS, fairly recent 11-current. > 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. Please show an exact minimal test case which reproduces what you consider the bug, with the comment about the expected outcome in the failing location.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160201165648.GM91220>