From owner-freebsd-fs@freebsd.org Tue Feb 2 18:51:21 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99DB1A981FF for ; Tue, 2 Feb 2016 18:51:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EDE01E7F for ; Tue, 2 Feb 2016 18:51:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x22d.google.com with SMTP id l66so36911752wml.0 for ; Tue, 02 Feb 2016 10:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=673SW3jUVZwsOZS82WBoTnoCdWp71ifhNt6PnRlgRXo=; b=sJdhtff64c/vSVFQttRpI961vDznbjkJgQ69yqrRhgYRIC7zdoCdlvGVpLCkwa//Te u9cAMLTkGKdXGaLItXCBwYOBkw9BJAT1u8fXiJp3EhmCbMi6IygSPRLnb0HBJLc8gwnE kL6ka47kvnZeEATHepJgczDyP4fP9RG1tl9smtEhuMHLsz9nr5vGo25e7wJvoaKRAS8Q W3rKTqIKYYLfWg7h+8BdMOE0/PC8Aj/5kL/64DbzeB9P2QlzlOtzyIL/8Kb1vwRUijkG dPqHHfeHBvuQo1pvqWVhObvTXY0L99D38BeNLpBT3NmuZ/DaPxU7fK/U2P5BNNSldoIe o3Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=673SW3jUVZwsOZS82WBoTnoCdWp71ifhNt6PnRlgRXo=; b=P19vfYcwmF/y8X+ZLGg3D5LugMFgOcM67OaXLRal0hHI60uetG9yMseYQePOYScSu1 OdqcOKWgps0/eBN9U8qS+wrDwvYl27A/VeINtm2TlQCn08x+hpY8KEv7rlfhcDtMGb7l W4bDCq/aTWbLo6W8/IRHEzMKYW/BN/aDGrsZLLTqsLI2DLUXEPObdq/SSgOa6RjIVGKW t4g+SVW3ptChoOwRyNORLtpqdlAyXl24ITqP6LCu+u+PGUzEDnHAvyxhWHwNT/QFppk4 ZcL43qGRauUSHgUkXikeJsgucLf8lxuICm2Z2ZvFJY3/It3JGm2coLT5ewfFyNEIWeAj e95w== X-Gm-Message-State: AG10YOQVO5v0pu6oLOHfCU5gyHfsCP/YKT2iKDTRJXJEAynuZTD0/5Ew7TWh4JmeD1j4CJsn6wX+qwkP+/bLhC28 MIME-Version: 1.0 X-Received: by 10.194.91.180 with SMTP id cf20mr30284311wjb.121.1454439079347; Tue, 02 Feb 2016 10:51:19 -0800 (PST) Received: by 10.27.39.195 with HTTP; Tue, 2 Feb 2016 10:51:19 -0800 (PST) In-Reply-To: <20160202132556.GV91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> <20160201182257.GN91220@kib.kiev.ua> <20160201194014.GQ91220@kib.kiev.ua> <20160202132556.GV91220@kib.kiev.ua> Date: Tue, 2 Feb 2016 10:51:19 -0800 Message-ID: Subject: Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) From: Maxim Sobolev To: Konstantin Belousov Cc: freebsd-fs@freebsd.org, Kirk McKusick Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 18:51:21 -0000 Here it is, works on UFS no problems here. ---- #include #include #include #include #include #include #include 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 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