From owner-freebsd-fs@freebsd.org Sun Jan 31 21:00:34 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 DB486A73322 for ; Sun, 31 Jan 2016 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9BD5EF for ; Sun, 31 Jan 2016 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0VL01Qn085275 for ; Sun, 31 Jan 2016 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201601312100.u0VL01Qn085275@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 31 Jan 2016 21:00:34 +0000 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: Sun, 31 Jan 2016 21:00:34 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 4 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon Feb 1 15:57:42 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 3B455A977B5 for ; Mon, 1 Feb 2016 15:57:42 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 E77EF3CB for ; Mon, 1 Feb 2016 15:57:41 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x232.google.com with SMTP id p63so77953877wmp.1 for ; Mon, 01 Feb 2016 07:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=TKiEcyW8IJjvA5A+4lOhu3pEUp15Mjsv84Oykb+OFn4=; b=jNiDsEWbvVf2WHM22KW2BxdOFVs2N7VH9+RlQZvWEH5wB1MACg8TSH4HfwGGsuhDfg xbqRYxikGTlakCIadyQ3U3NOXgkbCLyf84kPqPh1VFgVIJ9NYkgK1FGH/v4pn5L/1pu0 KvOlp0hGDHNtuydLQVjfN6SqSrxGybo5c1slFpiCTKOLoTVr6sevBW5el3W70NJoETqz 642GMLVuar49uCCOzGpoOdheDV8prgodXobrj/s+NmXSTqzYMJ4v3zzGXBupYleCI3Sh CnJUzjudMc1Mrg/3RgTW5zUDcKgUU57BluU7Hmx7hi9iHS35yAJQUjloVJ881E54g8X5 Cgmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=TKiEcyW8IJjvA5A+4lOhu3pEUp15Mjsv84Oykb+OFn4=; b=Klre/UkMMBcNmdQMQcQyssvFyNESsx5o3v3zv42E3BDJqJqPIn+o8q6DvzKbWUOOb/ RNBu6LHUiRTj52X4Pecuc3PYgWezKYXeWvDIMCsgucLqczweWs8l8z92XMh8kai9HLfO /P6Gux5jOz8XAqyZXKJUtRoo0SsfrZe6NDOaJ7GQQkpRXoJckpONr+ZAQyl0PlkF4AJy 8YTACdiLqJAIwbWFSiaaisRDAhjeuHOATkS4cgziHU4XENl0egDWeWqBO6GnTsaJRcen 1/vjk85mZWyOAvtkbmspPNCgPjnnpS/NH7ftGOICdI6R7SPsi51wiGZSiVK6A3SUmctu OO4Q== X-Gm-Message-State: AG10YOQzJQEzcq7Ju8EP9I65Uwf73/gb803ZwzC76U1ZXHMohjyUDVlpQCO1lCRuhBiVQgfXJIc+6nBV5k7E6tSE MIME-Version: 1.0 X-Received: by 10.194.192.71 with SMTP id he7mr27543943wjc.82.1454342260257; Mon, 01 Feb 2016 07:57:40 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.195 with HTTP; Mon, 1 Feb 2016 07:57:40 -0800 (PST) Date: Mon, 1 Feb 2016 07:57:40 -0800 X-Google-Sender-Auth: 1jmn6lj3Tgb2W_Aqhi5K4b_XJRQ Message-ID: Subject: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) From: Maxim Sobolev To: freebsd-fs@freebsd.org, Kirk McKusick , kib@freebsd.org 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: Mon, 01 Feb 2016 15:57:42 -0000 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. -Max From owner-freebsd-fs@freebsd.org Mon Feb 1 16:37:33 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 32F10A97644 for ; Mon, 1 Feb 2016 16:37:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2441C1C10 for ; Mon, 1 Feb 2016 16:37:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u11GbXMS091058 for ; Mon, 1 Feb 2016 16:37:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206820] [ext2fs] Panic when writing to ext3fs mounted as ext2fs Date: Mon, 01 Feb 2016 16:37:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Mon, 01 Feb 2016 16:37:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206820 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Feb 1 16:56:54 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 D528EA97E8F for ; Mon, 1 Feb 2016 16:56:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5653A9F0; Mon, 1 Feb 2016 16:56:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u11Gumu8067184 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Feb 2016 18:56:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u11Gumu8067184 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u11Gum3J067183; Mon, 1 Feb 2016 18:56:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Feb 2016 18:56:48 +0200 From: Konstantin Belousov To: Maxim Sobolev Cc: freebsd-fs@freebsd.org, Kirk McKusick Subject: Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) Message-ID: <20160201165648.GM91220@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Mon, 01 Feb 2016 16:56:54 -0000 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. From owner-freebsd-fs@freebsd.org Mon Feb 1 17:17:51 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 A03FCA97581 for ; Mon, 1 Feb 2016 17:17:51 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 30C5C173D for ; Mon, 1 Feb 2016 17:17:51 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x22f.google.com with SMTP id l66so80631914wml.0 for ; Mon, 01 Feb 2016 09:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=M1n+n8Ir3YhoiDIusVbeGI9fJwnN2mZCDyHQyscgUHQ=; b=pVvQLnWgBLxt39IUAsoi2xLCLaJ5s9rW6Y2zwNEc3U/skFt0z2mrNIkkq1w0xJnL+k vKs+DQ0If592N904BBpMvd2a++g18TE4KaXPT0wP1QvUHPL5ljoEiKMNloeRmT9PVuA4 wLGhzQPfi7p+REj4kPgZZhZi8ExAYzNcORWoac3FWxtq9U15fXyLiw8wZyEEfbFdWShm vJebtgoDq70X+wJ/+avooP6yGbvAfGmWxFVD17zvppMD+dhBnzKuzfZYW++jfUIb8cTn xeMCH7cpFVUrqAudEJYJc/ZEg/BbLu9q6hznWfZSN13LTOtNvUzNlcVyxyD13V20KsUB FPQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M1n+n8Ir3YhoiDIusVbeGI9fJwnN2mZCDyHQyscgUHQ=; b=NBHJJ9Wclq4Eo89j/amhBbaWKKiA9AC/BZK1XxtKGikTIyQ2DMIPLMMYCyc81zoGNV eb+1E5BlulFo5Lug3xora3uQYEawG3Obx3H3+na59OznwNc5wJbiUygyS0sMpe2bIuI4 7drQEYTtiIJloDPjdSvoXo7xe9D7qnXWhPd7H943B1jtHtC2t8+FvtQjqBDXbEswkpCm RNTm93Dmwwx6msR9BSFiGGL1vNUFUKKevI5tqZwGs0r7BrGCccQOhNpL+whFpLRd4we7 Md2wv/ZrycHh55eyXGOp09p+Eius+iv2iCkpSl6bTldO34DCty8uyVR/9p86XSc6Kqp0 hvzg== X-Gm-Message-State: AG10YOTNiT40qwMhwwx2XNlRQPT8afhijBj2nnBmcipnDPz+rIm9uG/Ij7lUnTJPQKb+e3TaQQazXTsv5dCHhjVx MIME-Version: 1.0 X-Received: by 10.28.61.70 with SMTP id k67mr13294819wma.90.1454347069455; Mon, 01 Feb 2016 09:17:49 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.195 with HTTP; Mon, 1 Feb 2016 09:17:49 -0800 (PST) In-Reply-To: <20160201165648.GM91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> Date: Mon, 1 Feb 2016 09:17:49 -0800 X-Google-Sender-Auth: -0gJIx5cFPHYOHDM4vczE3Uq9MA 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: Mon, 01 Feb 2016 17:17:51 -0000 Here it is: The expected outcome is return code 0, the failure condition is in the lseek() returning 4 (i.e. sizeof(int)), not -1. ------ #include #include #include #include #include #include int main(void) { char tempname[] = "/tmp/temp.XXXXXX"; char *fname; int fd; off_t hole; fname = mktemp(tempname); if (fname == NULL) { exit (1); } fd = open(fname, O_WRONLY | O_CREAT | O_TRUNC, DEFFILEMODE); if (fd == -1) { exit (1); } if (write(fd, &fd, sizeof(fd)) <= 0) { exit (1); } hole = lseek(fd, 0, SEEK_HOLE); close(fd); unlink(fname); if (hole >= 0) { fprintf(stderr, "lseek() returned %jd, not -1\n", (intmax_t)hole); exit (1); } exit (0); } ------ On Mon, Feb 1, 2016 at 8:56 AM, Konstantin Belousov wrote: > 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. > > From owner-freebsd-fs@freebsd.org Mon Feb 1 18:23:02 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 D6A74A97AC0 for ; Mon, 1 Feb 2016 18:23:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81AD517AD; Mon, 1 Feb 2016 18:23:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u11IMvkO023135 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Feb 2016 20:22:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u11IMvkO023135 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u11IMvaF023134; Mon, 1 Feb 2016 20:22:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Feb 2016 20:22:57 +0200 From: Konstantin Belousov To: Maxim Sobolev Cc: freebsd-fs@freebsd.org, Kirk McKusick Subject: Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) Message-ID: <20160201182257.GN91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Mon, 01 Feb 2016 18:23:03 -0000 On Mon, Feb 01, 2016 at 09:17:49AM -0800, Maxim Sobolev wrote: > Here it is: > > The expected outcome is return code 0, the failure condition is in the > lseek() returning 4 (i.e. sizeof(int)), not -1. > > ------ > #include > #include > #include > #include > #include > #include > > int main(void) > { > char tempname[] = "/tmp/temp.XXXXXX"; > char *fname; > int fd; > off_t hole; > > fname = mktemp(tempname); > if (fname == NULL) { > exit (1); > } > fd = open(fname, O_WRONLY | O_CREAT | O_TRUNC, DEFFILEMODE); > if (fd == -1) { > exit (1); > } > if (write(fd, &fd, sizeof(fd)) <= 0) { > exit (1); > } > hole = lseek(fd, 0, SEEK_HOLE); > close(fd); > unlink(fname); > if (hole >= 0) { > fprintf(stderr, "lseek() returned %jd, not -1\n", > (intmax_t)hole); > exit (1); > } > exit (0); > } > ------ I tested you program on both UFS and ZFS, and the behaviour is identical, lseek(SEEK_HOLE) points to the end of file. In fact, when I did UFS implementation, I most likely considered this case and tested ZFS compatibility, because the case is handled explicitely. Look at the lines 2193-2197 in kern/vfs_vnops.c:vn_bmap_seekhole(), esp. the comment. For me, the results of the test are reasonable. There is no data after EOF, and the idea of 'implicit hole' after EOF is one which is quite intuitive. > > > On Mon, Feb 1, 2016 at 8:56 AM, Konstantin Belousov > wrote: > > > 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. > > > > From owner-freebsd-fs@freebsd.org Mon Feb 1 19:22:20 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 EC0AAA97C51 for ; Mon, 1 Feb 2016 19:22:20 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 92D511084 for ; Mon, 1 Feb 2016 19:22:20 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x22f.google.com with SMTP id r129so86065469wmr.0 for ; Mon, 01 Feb 2016 11:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5XHIGGxfleYmkXbc9JUeLoO7PvtH8cPa/a7jVyFtsfA=; b=1M+rYPtb3mpUBil9BnGSoGQTY6tptThBa9vqSsNjGHpdwW/tG65lve8Yq2PTl8rrkS QV+05FvfpkSlZ2Nt8iwkg8fRJlhZ9a/HsaZ68loHezj4iSqJzsrDFUPZ2qdU+XuwgPZ5 Tveq/GCIsWNKfILm64OJs4xxWXVW7Jwfvn3c8mgFzSBAcFwk5sbnU//a3T9xdd2ofFdB j5waMqH8iQu6FUJk+pbQWoEaZyuVIxkumGU6Z3DcU8rwGmvZep7dxSr/spgCyNuNDXUA bKtk+8pblPST3gS6nXVJ+SYJvtqZZGHPRTsRMyZYL2HFXijZ5oxAUBwQmoRdq8rl4Rs3 X3Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5XHIGGxfleYmkXbc9JUeLoO7PvtH8cPa/a7jVyFtsfA=; b=UzmUJnSBODCe+G5qGLE4xONRtolJrAo2F4yyVrFBTondBd7ehaelitTFow2R5LIlNJ R0taZ2pb5jSa4cCYG8LC4hCnjGAjh7WiD1V5BKi3gPn+tSkAbZtaR55DyTCTIZTAWFQv 5bmRbpq58IEuAn4FqwPSF6ib+flqQi8Q8LYgwbgMSZjQnpzyBw7f4UkPLcvFqxG18unR A887t9NNrbq5Ll//15Tizi7jOfZKrfisscMZuR5Uv3XrPETujiWD8B0x556jeQ6y5ZPo nsQj6nHFxnbJS3QT2Ob96Zo483wy2qw5Flt1oG6LlXTaatJwTBK20tVdX3WLQ7ZKzd7N rWOQ== X-Gm-Message-State: AG10YOTtF0vjrsX2PoGCyjcHE4CKCwBi8H0I9yO5FmpXthzSFqPQa89+l7xhbugwpe89mKp/MyzEJC2NqEQAnXPp MIME-Version: 1.0 X-Received: by 10.28.1.23 with SMTP id 23mr12952224wmb.37.1454354538995; Mon, 01 Feb 2016 11:22:18 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.195 with HTTP; Mon, 1 Feb 2016 11:22:18 -0800 (PST) In-Reply-To: <20160201182257.GN91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> <20160201182257.GN91220@kib.kiev.ua> Date: Mon, 1 Feb 2016 11:22:18 -0800 X-Google-Sender-Auth: xbhdZSQI8Pvg5CM9JCZeBWm1pT0 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: Mon, 01 Feb 2016 19:22:21 -0000 Well, it's still seems to be quite obscure. At the very least, the lseek(2) manual page needs to reflect that. Right now it says: ERRORS [...] [ENXIO] For SEEK_DATA, there are no more data regions past the supplied offset. For SEEK_HOLE, there are no more holes past the supplied offset. Which is not true, the SEEK_HOLE would return st_size when there are no more holes past the supplied offset, not ENXIO. It is also interesting that somehow empty file is a special case as well. Both SEEK_HOLE and SEEK_DATA return -1 on those. Anybody who programs to that document would probably get as confused as myself. However, having said that, our cousin Linux behaves the same - i.e. returns EOF+1 on SEEK_HOLE and -1 on SEEK_DATA, and does the same for empty files, so at least we are consistent with that. -Max On Mon, Feb 1, 2016 at 10:22 AM, Konstantin Belousov wrote: > On Mon, Feb 01, 2016 at 09:17:49AM -0800, Maxim Sobolev wrote: > > Here it is: > > > > The expected outcome is return code 0, the failure condition is in the > > lseek() returning 4 (i.e. sizeof(int)), not -1. > > > > ------ > > #include > > #include > > #include > > #include > > #include > > #include > > > > int main(void) > > { > > char tempname[] = "/tmp/temp.XXXXXX"; > > char *fname; > > int fd; > > off_t hole; > > > > fname = mktemp(tempname); > > if (fname == NULL) { > > exit (1); > > } > > fd = open(fname, O_WRONLY | O_CREAT | O_TRUNC, DEFFILEMODE); > > if (fd == -1) { > > exit (1); > > } > > if (write(fd, &fd, sizeof(fd)) <= 0) { > > exit (1); > > } > > hole = lseek(fd, 0, SEEK_HOLE); > > close(fd); > > unlink(fname); > > if (hole >= 0) { > > fprintf(stderr, "lseek() returned %jd, not -1\n", > > (intmax_t)hole); > > exit (1); > > } > > exit (0); > > } > > ------ > I tested you program on both UFS and ZFS, and the behaviour is > identical, lseek(SEEK_HOLE) points to the end of file. In fact, when I > did UFS implementation, I most likely considered this case and tested > ZFS compatibility, because the case is handled explicitely. Look at the > lines 2193-2197 in kern/vfs_vnops.c:vn_bmap_seekhole(), esp. the comment. > > For me, the results of the test are reasonable. There is no data > after EOF, and the idea of 'implicit hole' after EOF is one which > is quite intuitive. > > > > > > > On Mon, Feb 1, 2016 at 8:56 AM, Konstantin Belousov > > > wrote: > > > > > 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. > > > > > > > > From owner-freebsd-fs@freebsd.org Mon Feb 1 19:40:25 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 3136EA97231 for ; Mon, 1 Feb 2016 19:40:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5C381899; Mon, 1 Feb 2016 19:40:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u11JeFt2040703 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Feb 2016 21:40:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u11JeFt2040703 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u11JeESv040702; Mon, 1 Feb 2016 21:40:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Feb 2016 21:40:14 +0200 From: Konstantin Belousov To: Maxim Sobolev Cc: freebsd-fs@freebsd.org, Kirk McKusick Subject: Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) Message-ID: <20160201194014.GQ91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> <20160201182257.GN91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Mon, 01 Feb 2016 19:40:25 -0000 On Mon, Feb 01, 2016 at 11:22:18AM -0800, Maxim Sobolev wrote: > Well, it's still seems to be quite obscure. At the very least, the lseek(2) > manual page needs to reflect that. Right now it says: > > ERRORS > [...] > [ENXIO] For SEEK_DATA, there are no more data regions past > the > supplied offset. For SEEK_HOLE, there are no more > holes past the supplied offset. > > Which is not true, the SEEK_HOLE would return st_size when there are no > more holes past the supplied offset, not ENXIO. It is also interesting that > somehow empty file is a special case as well. Both SEEK_HOLE and SEEK_DATA > return -1 on those. Anybody who programs to that document would probably > get as confused as myself. > > However, having said that, our cousin Linux behaves the same - i.e. returns > EOF+1 on SEEK_HOLE and -1 on SEEK_DATA, and does the same for empty files, > so at least we are consistent with that. Actually, since you referred to the man page for lseek(2), which seems to be copied from the Solaris man page: ... The existence of a hole at the end of every data region allows for easy programming and implies that a virtual hole exists at the end of the file. ... And, the text you quoted, does not imply that the call must return ENXIO at the EOF for hole. It only allows the call to do it, but other language makes this unreasonable. Note that it is Solaris, not Linux, which implementation of the SEEK_HOLE and SEEK_DATA is the arbitration sample for the behavior. We got it with the ZFS import. Our UFS implementation, and whatever Linux does, are only reimplementation without clean documentation, and were done by observing ZFS behaviour. From owner-freebsd-fs@freebsd.org Mon Feb 1 20:14:32 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 AA258A9855D for ; Mon, 1 Feb 2016 20:14:32 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 390361436 for ; Mon, 1 Feb 2016 20:14:32 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x233.google.com with SMTP id p63so87926000wmp.1 for ; Mon, 01 Feb 2016 12:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2S9Lqhbhw9s88rna0py4JdnB83J/FRWCED/VQFHXUsc=; b=NZxClzpqxu+Hmu7BU9OA+y6FsHfA44qh9zmF4ZKu89QyAqvoWx/odO3AEGcXXhWSZp AIAw+gOy1d0uGbgRG1PrBedCrhonf8wodal9EAhZ7xrkokKb0qeqM6AL987+QlaL+/hW iJZwZgUUJ/tuwWXaqM+xw7nkPUaPvGVYt0VerE4ymAGS8XQgWtyQc3CnT4jKWH8QPyOe 9gmumxgwwgC+DH1z1CZNfwVPbbM9LJ/bICiNZVYhxtwdE++0/bu+0d7ttwygt3A5NfSq iU4WOvdX2/OyIeEqxqdLkj2ONgmJNPDWLJw1yXtKRkX8Np1JCuHB3mp8kFdfJCk8/edF h9eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2S9Lqhbhw9s88rna0py4JdnB83J/FRWCED/VQFHXUsc=; b=VTBztX9NoxBvpkD3Jaropsyc/OjXp9lzQ3zFbNAWbTFbotppUvK8jlm1HuAJxIWgP1 kaKdSgk6nOOvaPzj0jQQDGom08yo1C3XAypXcSP5EBCqDQCpVVhM8SI/G+aMv0pa/Qey 2Jpd2FToKsyqJ1872glWHcMgj+GGjfBMw6xc0G+O/GQGfxT2ZZM7HUBQtFlT6IZGr0Xu Beg3EuCelrvGjjiIcG23nQVjiJiTyBm0ti/yZFVRpsCBDBiXDjn5F9BeNbfkjTP4lk+J Z0uw8f9+GmHmOsTuuP7svmoRm86qPv4KFyQITVoE8qzgKao3dKzolHeqdqS5ndZqOaLE ZGUw== X-Gm-Message-State: AG10YOSscBsDydTK3BUU2V/c1z2D43d9C7UylXPZtE8YSXQ1yXQaTITsriPXqDEB9TcpbVeWGAGmKU2W4HOOszTn MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr24198432wjc.137.1454357670726; Mon, 01 Feb 2016 12:14:30 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.195 with HTTP; Mon, 1 Feb 2016 12:14:30 -0800 (PST) In-Reply-To: <20160201194014.GQ91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> <20160201182257.GN91220@kib.kiev.ua> <20160201194014.GQ91220@kib.kiev.ua> Date: Mon, 1 Feb 2016 12:14:30 -0800 X-Google-Sender-Auth: g4RrwPqnFy1djucb__5Mm7Kud-U 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: Mon, 01 Feb 2016 20:14:32 -0000 Yeah, I've noticed that text now. It looks a lot like the sentence has been copied around and some part of it had lost in transition. In any case here is a small manpage patch to make a "vurtual hole" more pronounced and also explain how it affects return value of the syscall. https://reviews.freebsd.org/D5162 On Mon, Feb 1, 2016 at 11:40 AM, Konstantin Belousov wrote: > On Mon, Feb 01, 2016 at 11:22:18AM -0800, Maxim Sobolev wrote: > > Well, it's still seems to be quite obscure. At the very least, the > lseek(2) > > manual page needs to reflect that. Right now it says: > > > > ERRORS > > [...] > > [ENXIO] For SEEK_DATA, there are no more data regions > past > > the > > supplied offset. For SEEK_HOLE, there are no > more > > holes past the supplied offset. > > > > Which is not true, the SEEK_HOLE would return st_size when there are no > > more holes past the supplied offset, not ENXIO. It is also interesting > that > > somehow empty file is a special case as well. Both SEEK_HOLE and > SEEK_DATA > > return -1 on those. Anybody who programs to that document would probably > > get as confused as myself. > > > > However, having said that, our cousin Linux behaves the same - i.e. > returns > > EOF+1 on SEEK_HOLE and -1 on SEEK_DATA, and does the same for empty > files, > > so at least we are consistent with that. > > Actually, since you referred to the man page for lseek(2), which seems to > be copied from the Solaris man page: > ... > The existence of a hole at the end of every data region allows for easy > programming and implies that a virtual hole exists at the end of the > file. > ... > > And, the text you quoted, does not imply that the call must return ENXIO > at the EOF for hole. It only allows the call to do it, but other language > makes this unreasonable. > > Note that it is Solaris, not Linux, which implementation of the SEEK_HOLE > and SEEK_DATA is the arbitration sample for the behavior. We got it with > the ZFS import. Our UFS implementation, and whatever Linux does, are only > reimplementation without clean documentation, and were done by observing > ZFS behaviour. > > From owner-freebsd-fs@freebsd.org Mon Feb 1 22:17:16 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 78B9BA98D98 for ; Mon, 1 Feb 2016 22:17:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB53218CC for ; Mon, 1 Feb 2016 22:17:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u11MHAYB076440 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 00:17:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u11MHAYB076440 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u11MHAn6076439; Tue, 2 Feb 2016 00:17:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Feb 2016 00:17:10 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160201221710.GR91220@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Mon, 01 Feb 2016 22:17:16 -0000 On Mon, Jan 18, 2016 at 11:25:16PM -0500, Rick Macklem wrote: > Kostik wrote: > > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote: > > > Kostik wrote: > > > > Was IO_EXT flag passed to the ffs_truncate() invocation where the > > > > assert ffs_truncate3 fired ? > > > > > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified both > > > IO_EXT | IO_NORMAL. > > > > Please try this. > > > Still happens. I put the old panic test in, but with a printf() instead > of panic() and the printf() happens with this patch. > Btw, whenever I've looked, the entry is on the clean list. > No other panics happen and the file system fsck's fine after the test run. I thought that you posted a stand-alone program which triggered the issue on non-SU mounts, but I cannot find it. Does such program exist, or this is just me misremembering ? From owner-freebsd-fs@freebsd.org Tue Feb 2 01:08:31 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 4BCB1A97A5D for ; Tue, 2 Feb 2016 01:08:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id ECD87DCD for ; Tue, 2 Feb 2016 01:08:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:c3yT5BE62O/GqrQ6BVzG9Z1GYnF86YWxBRYc798ds5kLTJ75r86wAkXT6L1XgUPTWs2DsrQf27WQ6vqrAjJIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/niKbrodaIPU1hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv+YJa6jxfrw5QLpEF3xmdjltvIy4/SXEGCiI4GAAW2MKkxwAKQXB6wzhWYm55ij9rfZ82yOXOeX5SLk1XXKp6KI9GzHyjyJSDT8y8ynyg8dziK9e6Ea7ohV0wIrZZamIM/Vjc6fFfZURTDwSDY5qSyVdD9bkPMM0BO0bMLMd9tGlqg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CqBAAGALBW/61jaINehH+IU7NMhg8CgXYQAQEBAQEBAQGBCYItghUBAQQjVhACAQgOCgICDRkCAlcCBIguryqOcQEBAQEBBQEBAQEBARp7hRSEN4QCEQGDHoE6BY4ZiFaPJoRCiFNEjXgCNyuCAhmBbx6IaTR8AQEB X-IronPort-AV: E=Sophos;i="5.22,382,1449550800"; d="scan'208";a="264164337" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 01 Feb 2016 20:07:20 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 7799A15F55D; Mon, 1 Feb 2016 20:07:20 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rxhM7V0BXwEC; Mon, 1 Feb 2016 20:07:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 15F7315F565; Mon, 1 Feb 2016 20:07:20 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uqTGqqTwGQf3; Mon, 1 Feb 2016 20:07:20 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id EF10915F55D; Mon, 1 Feb 2016 20:07:19 -0500 (EST) Date: Mon, 1 Feb 2016 20:07:19 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Cc: FreeBSD Filesystems , Kirk McKusick Message-ID: <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20160201221710.GR91220@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> <20160201221710.GR91220@kib.kiev.ua> Subject: Re: panic ffs_truncate3 (maybe fuse being evil) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF44 (Win)/8.0.9_GA_6191) Thread-Topic: panic ffs_truncate3 (maybe fuse being evil) Thread-Index: SEAY664I9MD6vHPsP86SX673OyeM9A== 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 01:08:31 -0000 Kostik wrote: > On Mon, Jan 18, 2016 at 11:25:16PM -0500, Rick Macklem wrote: > > Kostik wrote: > > > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote: > > > > Kostik wrote: > > > > > Was IO_EXT flag passed to the ffs_truncate() invocation where the > > > > > assert ffs_truncate3 fired ? > > > > > > > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified both > > > > IO_EXT | IO_NORMAL. > > > > > > Please try this. > > > > > Still happens. I put the old panic test in, but with a printf() instead > > of panic() and the printf() happens with this patch. > > Btw, whenever I've looked, the entry is on the clean list. > > No other panics happen and the file system fsck's fine after the test run. > > I thought that you posted a stand-alone program which triggered the issue > on non-SU mounts, but I cannot find it. Does such program exist, or this > is just me misremembering ? > Nope. I do a test run using GlusterFS (a FreeBSD kernel build with the sources on GlusterFS) where the bricks are on UFS file systems with SU disabled. To be honest, I've been using ZFS for tests lately, so I'm not even sure I remember exactly what the test setup was, but I think the above is it. (It takes 2-3hrs for an occurrence to happen.) I did plan on taking a look at vinvalbuf(..V_ALT..), since that is what I think should be getting rid of the extended attribute block, but haven't done so. If you have another patch to try, email it and I'll try and reproduce the failure without/with the patch. rick From owner-freebsd-fs@freebsd.org Tue Feb 2 05:17:03 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 C471CA97014 for ; Tue, 2 Feb 2016 05:17:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 59ECC1F72 for ; Tue, 2 Feb 2016 05:17:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x231.google.com with SMTP id l66so99924797wml.0 for ; Mon, 01 Feb 2016 21:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jNfIEsN6JXND9ch8Xlr6chvanFH7pHjr8ug6efbgcbA=; b=yeweIQXtzHnYbPFyLqQhLalWv1Pc01brKl31GU3tzmDRtD1NE4/Y/PWTGQlRSO9Zww Ao/S9WmSWGegM26wSMynb8Q3arqiJHyDXrmYiGFgs2SqVGNECbFgqZO3RwSkyTrxQQfC Ygo1/FVC7B3fbWSGIE/uKJJT02Ak3Y5PHQucmdjG3Q970KDei6iebtpW07lpyKZdu1hE Jr0vdMed964ZOlQxCn9c1DDCeQ202F2xnUBRJO9/evbRFJ/mPZ7BEeDp6G7B8+iKEE8J CzazPd5E1Ht/h9eq1ZPZLFkwxi2jEg9XkDWFWKfBe2kDppFMEybrtlosTnyP+e2wJqnO FTGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jNfIEsN6JXND9ch8Xlr6chvanFH7pHjr8ug6efbgcbA=; b=A/h3NKasH3qQNYaYohxo7ZG9pmMkdqc3K/4kmUOxc8UW7Sq/N/SbHmGXsF5eCEo47F OfaqflfUAa1jf3uvvjIgouF1onRNZF/k3nDPwvmnQMLlv7Jm8u65KqmQrUvLVuTX2OSN 9Zk4QtWtlgjZ3XVldAdHWAhLVru5KSDjJs2egpoMkW6ZZuIHJ9+z0dxapNfaE9m+lh7Y SFYHOS6UeydDaoFBYPBAHuM5YLnCax5eglSc+liMEzZdilWSjHnFR7WM4eTjU8UqT1o9 0xXmtbMWRpWQJlYwdv4ZCkTJ/DJG6Qk5uxTvG07iD4jmikUoUuA1bwisAEgOgv/S9NA8 InCA== X-Gm-Message-State: AG10YORUi8vgT40GA47dVtKsAFO/2RW1y5ufpsMy/gcUIZcIariKmDeoVj/8m0Gkpg02iCd+WbkGpfC01YFDbohZ MIME-Version: 1.0 X-Received: by 10.194.192.71 with SMTP id he7mr30949826wjc.82.1454390220627; Mon, 01 Feb 2016 21:17:00 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.195 with HTTP; Mon, 1 Feb 2016 21:17:00 -0800 (PST) In-Reply-To: References: <20160201165648.GM91220@kib.kiev.ua> <20160201182257.GN91220@kib.kiev.ua> <20160201194014.GQ91220@kib.kiev.ua> Date: Mon, 1 Feb 2016 21:17:00 -0800 X-Google-Sender-Auth: DAyD825Bgnim-A0aUywop-OfErU 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 05:17:03 -0000 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 ----- 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. -Max On Mon, Feb 1, 2016 at 12:14 PM, Maxim Sobolev wrote: > Yeah, I've noticed that text now. It looks a lot like the sentence has > been copied around and some part of it had lost in transition. In any case > here is a small manpage patch to make a "vurtual hole" more pronounced and > also explain how it affects return value of the syscall. > > https://reviews.freebsd.org/D5162 > > On Mon, Feb 1, 2016 at 11:40 AM, Konstantin Belousov > wrote: > >> On Mon, Feb 01, 2016 at 11:22:18AM -0800, Maxim Sobolev wrote: >> > Well, it's still seems to be quite obscure. At the very least, the >> lseek(2) >> > manual page needs to reflect that. Right now it says: >> > >> > ERRORS >> > [...] >> > [ENXIO] For SEEK_DATA, there are no more data regions >> past >> > the >> > supplied offset. For SEEK_HOLE, there are no >> more >> > holes past the supplied offset. >> > >> > Which is not true, the SEEK_HOLE would return st_size when there are no >> > more holes past the supplied offset, not ENXIO. It is also interesting >> that >> > somehow empty file is a special case as well. Both SEEK_HOLE and >> SEEK_DATA >> > return -1 on those. Anybody who programs to that document would probably >> > get as confused as myself. >> > >> > However, having said that, our cousin Linux behaves the same - i.e. >> returns >> > EOF+1 on SEEK_HOLE and -1 on SEEK_DATA, and does the same for empty >> files, >> > so at least we are consistent with that. >> >> Actually, since you referred to the man page for lseek(2), which seems to >> be copied from the Solaris man page: >> ... >> The existence of a hole at the end of every data region allows for easy >> programming and implies that a virtual hole exists at the end of the >> file. >> ... >> >> And, the text you quoted, does not imply that the call must return ENXIO >> at the EOF for hole. It only allows the call to do it, but other language >> makes this unreasonable. >> >> Note that it is Solaris, not Linux, which implementation of the SEEK_HOLE >> and SEEK_DATA is the arbitration sample for the behavior. We got it with >> the ZFS import. Our UFS implementation, and whatever Linux does, are only >> reimplementation without clean documentation, and were done by observing >> ZFS behaviour. >> >> > From owner-freebsd-fs@freebsd.org Tue Feb 2 06:11:00 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 B9599A985F1; Tue, 2 Feb 2016 06:11:00 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 2C0911852; Tue, 2 Feb 2016 06:11:00 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id j78so41538814lfb.1; Mon, 01 Feb 2016 22:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lZ3tdqE/YuX/cl1+JZKD2H6/zOzTPVplFBdq3hS6kIY=; b=e25KVCtvBKtYnLLvJdBHNbMe4shuXkxSCxbFlm/RSBW+7D285n1Mq9LjO+BX68sfN7 RXQjPHB7wgd84oCjGiXHAFYlWnSzOhHw/Yc7BQxL22RKOO1Blhcx4kUsgTf9jlhl1Bw9 rimj6pI6CZEiCnbHjZJvRtNiFd3Ta55Vwy0bLm8tM9SE+QnhNhc1pcgN7GFpquPUhqFv Avyk0TREjkfbCpXh83qO+EJhwOzDLWmkhcyKMBVAb+ljPKYehG7MAtqyiDlhJhKn77Iw MvUSOIgJU/kL4VjZRr4qAOeE5b0obwA6mzIU5Try/w+iKl+Txj2ngbyoPCPs4sqobtLj szWA== 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=lZ3tdqE/YuX/cl1+JZKD2H6/zOzTPVplFBdq3hS6kIY=; b=HMix4N0i7F4dlpTRVT5pfZiICs9BgWuSN66eU9Zd22CjGEEaUwGkpIQcrcTMuUoXHu /ksxs0WHkR90D+tAegir/oPmMiIgzMARFPvEl4cCaBug2vjEc6kZnXOEBSgJ4hAxgL9f cmTDwuM1EEpqfHv+vzljIQ3Go2leF6qng4KAlXb7u+NWkTFjS4l6/2+CCe8booRiJR0y UdZDgdVuJbRPJMDrJiGqX30iC1thtO+6psDOcczHXOafn6ycc9uapop1msBT0VPQsNZH fVz6T5M4qvr8qxlSBZl8msOuProuXMo4EKpI2ExgaUfKuZyvZ1/VwNfe4I1Cj2wUNKUl vakg== X-Gm-Message-State: AG10YOQJVxmSOEcb99LdAufXSnV+XG81QwAtZRBb/ANr7rClQpXC+PDeIQTuQ+lW8gZkXofWJL0SgLXy3nkdFw== MIME-Version: 1.0 X-Received: by 10.25.65.5 with SMTP id o5mr9101477lfa.38.1454393458239; Mon, 01 Feb 2016 22:10:58 -0800 (PST) Received: by 10.25.89.10 with HTTP; Mon, 1 Feb 2016 22:10:58 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Feb 2016 07:10:58 +0100 Message-ID: Subject: Re: NFS unstable with high load on server From: Ben Woods To: Vick Khera Cc: "freebsd-questions@freebsd.org" , freebsd-fs@freebsd.org 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 06:11:00 -0000 On Monday, 1 February 2016, Vick Khera wrote: > I have a handful of servers at my data center all running FreeBSD 10.2. On > one of them I have a copy of the FreeBSD sources shared via NFS. When this > server is running a large poudriere run re-building all the ports I need, > the clients' NFS mounts become unstable. That is, the clients keep getting > read failures. The interactive performance of the NFS server is just fine, > however. The local file system is a ZFS mirror. > > What could be causing NFS to be unstable in this situation? > > Specifics: > > Server "lorax" FreeBSD 10.2-RELEASE-p7 kernel locally compiled, with NFS > server and ZFS as dynamic kernel modules. 16GB RAM, Xeon 3.1GHz quad > processor. > > The directory /u/lorax1 a ZFS dataset on a mirrored pool, and is NFS > exported via the ZFS exports file. I put the FreeBSD sources on this > dataset and symlink to /usr/src. > > > Client "bluefish" FreeBSD 10.2-RELEASE-p5 kernel locally compiled, NFS > client built in to kernel. 32GB RAM, Xeon 3.1GHz quad processor (basically > same hardware but more RAM). > > The directory /n/lorax1 is NFS mounted from lorax via autofs. The NFS > options are "intr,nolockd". /usr/src is symlinked to the sources in that > NFS mount. > > > What I observe: > > [lorax]~% cd /usr/src > [lorax]src% svn status > [lorax]src% w > 9:12AM up 12 days, 19:19, 4 users, load averages: 4.43, 4.45, 3.61 > USER TTY FROM LOGIN@ IDLE WHAT > vivek pts/0 vick.int.kcilink.com 8:44AM - tmux: client > (/tmp/ > vivek pts/1 tmux(19747).%0 8:44AM 19 sed > y%*+%pp%;s%[^_a > vivek pts/2 tmux(19747).%1 8:56AM - w > vivek pts/3 tmux(19747).%2 8:56AM - slogin > bluefish-prv > [lorax]src% pwd > /u/lorax1/usr10/src > > So right now the load average is more than 1 per processor on lorax. I can > quite easily run "svn status" on the source directory, and the interactive > performance is pretty snappy for editing local files and navigating around > the file system. > > > On the client: > > [bluefish]~% cd /usr/src > [bluefish]src% pwd > /n/lorax1/usr10/src > [bluefish]src% svn status > svn: E070008: Can't read directory '/n/lorax1/usr10/src/contrib/sqlite3': > Partial results are valid but processing is incomplete > [bluefish]src% svn status > svn: E070008: Can't read directory '/n/lorax1/usr10/src/lib/libfetch': > Partial results are valid but processing is incomplete > [bluefish]src% svn status > svn: E070008: Can't read directory > '/n/lorax1/usr10/src/release/picobsd/tinyware/msg': Partial results are > valid but processing is incomplete > [bluefish]src% w > 9:14AM up 93 days, 23:55, 1 user, load averages: 0.10, 0.15, 0.15 > USER TTY FROM LOGIN@ IDLE WHAT > vivek pts/0 lorax-prv.kcilink.com 8:56AM - w > [bluefish]src% df . > Filesystem 1K-blocks Used Avail Capacity Mounted on > lorax-prv:/u/lorax1 932845181 6090910 926754271 1% /n/lorax1 > > > What I see is more or less random failures to read the NFS volume. When the > server is not so busy running poudriere builds, the client never has any > failures. > > I also observe this kind of failure doing buildworld or installworld on > the client when the server is busy -- I get strange random failures reading > the files causing the build or install to fail. > > My workaround is to not do build/installs on client machines when the NFS > server is busy doing large jobs like building all packages, but there is > definitely something wrong here I'd like to fix. I observe this on all the > local NFS clients. I rebooted the server before to try to clear this up but > it did not fix it. > > Any help would be appreciated. > I just wanted to point out that I am experiencing this exact same issue in my home setup. Performing an installworld from an NFS mount works perfectly, until I start running poudriere on the NFS server. Then I start getting NFS timeouts and the installworld fails. The NFS server is also using ZFS, but the NFS export in my case is being done via the ZFS property "sharenfs" (I am not using the /etc/exports file). I suspect this will boil down to a ZFS tuning issue, where poudriere and installworld are both stress testing the server. Both of these would obviously cause significant memory and CPU usage, and the "recently used" portion of the ARC to be constantly flushed as they access a large number of different files. It might be interesting if you could report the output of the heading lines (including memory and ARC details) from the "top" command before/after running poudriere and attempting the installworld. Regards, Ben -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-fs@freebsd.org Tue Feb 2 06:26:56 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 10A4BA98B0F; Tue, 2 Feb 2016 06:26:56 +0000 (UTC) (envelope-from spork@bway.net) Received: from smtp1.bway.net (smtp1.v6.bway.net [IPv6:2607:d300:1::27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7A511F32; Tue, 2 Feb 2016 06:26:55 +0000 (UTC) (envelope-from spork@bway.net) Received: from frankentosh.sporklab.com (foon.sporktines.com [96.57.144.66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp1.bway.net (Postfix) with ESMTPSA id 5A03395854; Tue, 2 Feb 2016 01:26:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bway.net; s=mail; t=1454394404; bh=Z8V/1DQgUvKQRuYpDJCHcKXtgCNlOhVLAm7n9MeIdx8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fZZuftmuw9BQTXaIfbebFtTv3wqS2+m7DxHWT3aSfmXp5CGUdLuK64wWJ+/OTZpF+ nwNw60WiiGU4U/HFYhkvPjlXvqSYrpXCij3vHy9IRnqyibjQT4LM5OaPmbXU4uLFz2 wohu0XVppzkaAcvaHaTWHS0PifLRPxBdRnYzZy0w= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: NFS unstable with high load on server From: Charles Sprickman In-Reply-To: Date: Tue, 2 Feb 2016 01:26:43 -0500 Cc: Vick Khera , freebsd-fs@freebsd.org, "freebsd-questions@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5EAD4A4A-211F-451E-A3B9-752DAC6D94B4@bway.net> References: To: Ben Woods X-Mailer: Apple Mail (2.3112) 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 06:26:56 -0000 On Feb 2, 2016, at 1:10 AM, Ben Woods wrote: >=20 > On Monday, 1 February 2016, Vick Khera wrote: >=20 >> I have a handful of servers at my data center all running FreeBSD = 10.2. On >> one of them I have a copy of the FreeBSD sources shared via NFS. When = this >> server is running a large poudriere run re-building all the ports I = need, >> the clients' NFS mounts become unstable. That is, the clients keep = getting >> read failures. The interactive performance of the NFS server is just = fine, >> however. The local file system is a ZFS mirror. >>=20 >> What could be causing NFS to be unstable in this situation? >>=20 >> Specifics: >>=20 >> Server "lorax" FreeBSD 10.2-RELEASE-p7 kernel locally compiled, with = NFS >> server and ZFS as dynamic kernel modules. 16GB RAM, Xeon 3.1GHz quad >> processor. >>=20 >> The directory /u/lorax1 a ZFS dataset on a mirrored pool, and is NFS >> exported via the ZFS exports file. I put the FreeBSD sources on this >> dataset and symlink to /usr/src. >>=20 >>=20 >> Client "bluefish" FreeBSD 10.2-RELEASE-p5 kernel locally compiled, = NFS >> client built in to kernel. 32GB RAM, Xeon 3.1GHz quad processor = (basically >> same hardware but more RAM). >>=20 >> The directory /n/lorax1 is NFS mounted from lorax via autofs. The NFS >> options are "intr,nolockd". /usr/src is symlinked to the sources in = that >> NFS mount. >>=20 >>=20 >> What I observe: >>=20 >> [lorax]~% cd /usr/src >> [lorax]src% svn status >> [lorax]src% w >> 9:12AM up 12 days, 19:19, 4 users, load averages: 4.43, 4.45, 3.61 >> USER TTY FROM LOGIN@ IDLE WHAT >> vivek pts/0 vick.int.kcilink.com 8:44AM - tmux: = client >> (/tmp/ >> vivek pts/1 tmux(19747).%0 8:44AM 19 sed >> y%*+%pp%;s%[^_a >> vivek pts/2 tmux(19747).%1 8:56AM - w >> vivek pts/3 tmux(19747).%2 8:56AM - slogin >> bluefish-prv >> [lorax]src% pwd >> /u/lorax1/usr10/src >>=20 >> So right now the load average is more than 1 per processor on lorax. = I can >> quite easily run "svn status" on the source directory, and the = interactive >> performance is pretty snappy for editing local files and navigating = around >> the file system. >>=20 >>=20 >> On the client: >>=20 >> [bluefish]~% cd /usr/src >> [bluefish]src% pwd >> /n/lorax1/usr10/src >> [bluefish]src% svn status >> svn: E070008: Can't read directory = '/n/lorax1/usr10/src/contrib/sqlite3': >> Partial results are valid but processing is incomplete >> [bluefish]src% svn status >> svn: E070008: Can't read directory = '/n/lorax1/usr10/src/lib/libfetch': >> Partial results are valid but processing is incomplete >> [bluefish]src% svn status >> svn: E070008: Can't read directory >> '/n/lorax1/usr10/src/release/picobsd/tinyware/msg': Partial results = are >> valid but processing is incomplete >> [bluefish]src% w >> 9:14AM up 93 days, 23:55, 1 user, load averages: 0.10, 0.15, 0.15 >> USER TTY FROM LOGIN@ IDLE WHAT >> vivek pts/0 lorax-prv.kcilink.com 8:56AM - w >> [bluefish]src% df . >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> lorax-prv:/u/lorax1 932845181 6090910 926754271 1% /n/lorax1 >>=20 >>=20 >> What I see is more or less random failures to read the NFS volume. = When the >> server is not so busy running poudriere builds, the client never has = any >> failures. >>=20 >> I also observe this kind of failure doing buildworld or installworld = on >> the client when the server is busy -- I get strange random failures = reading >> the files causing the build or install to fail. >>=20 >> My workaround is to not do build/installs on client machines when the = NFS >> server is busy doing large jobs like building all packages, but there = is >> definitely something wrong here I'd like to fix. I observe this on = all the >> local NFS clients. I rebooted the server before to try to clear this = up but >> it did not fix it. >>=20 >> Any help would be appreciated. >>=20 >=20 > I just wanted to point out that I am experiencing this exact same = issue in > my home setup. >=20 > Performing an installworld from an NFS mount works perfectly, until I = start > running poudriere on the NFS server. Then I start getting NFS timeouts = and > the installworld fails. >=20 > The NFS server is also using ZFS, but the NFS export in my case is = being > done via the ZFS property "sharenfs" (I am not using the /etc/exports = file). Me three. I=E2=80=99m actually updating a small group of servers now = and started=20 blowing up my installworlds by trying to do some poudriere builds at the = same=20 time. Very repeatable. Of note, I=E2=80=99m on 9.3, and saw this on = 8.4 as well. If I=20 track down the client-side failures, it=E2=80=99s always =E2=80=9Cpermissi= on denied=E2=80=9D. Thanks, Charles >=20 > I suspect this will boil down to a ZFS tuning issue, where poudriere = and > installworld are both stress testing the server. Both of these would > obviously cause significant memory and CPU usage, and the "recently = used" > portion of the ARC to be constantly flushed as they access a large = number > of different files. >=20 > It might be interesting if you could report the output of the heading = lines > (including memory and ARC details) from the "top" command before/after > running poudriere and attempting the installworld. >=20 > Regards, > Ben >=20 >=20 > --=20 >=20 > -- > From: Benjamin Woods > woodsb02@gmail.com > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Tue Feb 2 13:26:01 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 A189DA97CCA for ; Tue, 2 Feb 2016 13:26:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 376F8B9E; Tue, 2 Feb 2016 13:26:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u12DPuLB086991 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 15:25:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u12DPuLB086991 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u12DPudA086990; Tue, 2 Feb 2016 15:25:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Feb 2016 15:25:56 +0200 From: Konstantin Belousov To: Maxim Sobolev Cc: freebsd-fs@freebsd.org, Kirk McKusick Subject: Re: Inconsistency between lseek(SEEK_HOLE) and lseek(SEEK_DATA) Message-ID: <20160202132556.GV91220@kib.kiev.ua> References: <20160201165648.GM91220@kib.kiev.ua> <20160201182257.GN91220@kib.kiev.ua> <20160201194014.GQ91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 13:26:01 -0000 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. From owner-freebsd-fs@freebsd.org Tue Feb 2 14:48:22 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 BA82FA99E06 for ; Tue, 2 Feb 2016 14:48:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 656BA1BD8 for ; Tue, 2 Feb 2016 14:48:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u12EmCRA061406 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 16:48:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u12EmCRA061406 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u12EmCOU061405; Tue, 2 Feb 2016 16:48:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Feb 2016 16:48:12 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160202144812.GZ91220@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> <20160201221710.GR91220@kib.kiev.ua> <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 14:48:22 -0000 On Mon, Feb 01, 2016 at 08:07:19PM -0500, Rick Macklem wrote: > Kostik wrote: > > On Mon, Jan 18, 2016 at 11:25:16PM -0500, Rick Macklem wrote: > > > Kostik wrote: > > > > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote: > > > > > Kostik wrote: > > > > > > Was IO_EXT flag passed to the ffs_truncate() invocation where the > > > > > > assert ffs_truncate3 fired ? > > > > > > > > > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified both > > > > > IO_EXT | IO_NORMAL. > > > > > > > > Please try this. > > > > > > > Still happens. I put the old panic test in, but with a printf() instead > > > of panic() and the printf() happens with this patch. > > > Btw, whenever I've looked, the entry is on the clean list. > > > No other panics happen and the file system fsck's fine after the test run. > > > > I thought that you posted a stand-alone program which triggered the issue > > on non-SU mounts, but I cannot find it. Does such program exist, or this > > is just me misremembering ? > > > Nope. I do a test run using GlusterFS (a FreeBSD kernel build with the sources > on GlusterFS) where the bricks are on UFS file systems with SU disabled. > > To be honest, I've been using ZFS for tests lately, so I'm not even sure I > remember exactly what the test setup was, but I think the above is it. > (It takes 2-3hrs for an occurrence to happen.) > > I did plan on taking a look at vinvalbuf(..V_ALT..), since that is what I > think should be getting rid of the extended attribute block, but haven't > done so. I doubt that this is vinvalbuf(), more likely it is stray buffer forgotten by some cleanup code. Note that ffs_truncate() condition to call vinvalbuf(V_ALT) is that IO_EXT flag is passed and dinode di_extsize field value is > 0. > > If you have another patch to try, email it and I'll try and reproduce the > failure without/with the patch. I asked about the test program to be able to trace the issue. I do think that the IO_UNIT patch fixes some situations where the buffer can be left on the vnode queue. I did not found any other places so far. From owner-freebsd-fs@freebsd.org Tue Feb 2 15:33:44 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 45F03A9701C for ; Tue, 2 Feb 2016 15:33:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 371CE197C for ; Tue, 2 Feb 2016 15:33:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u12FXhb2052070 for ; Tue, 2 Feb 2016 15:33:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Tue, 02 Feb 2016 15:33:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daniel@blodan.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 15:33:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #14 from Daniel Ylitalo --- I've recompiled the kernel with the patch applied, I'll wait for it to happ= en again. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Feb 2 16:54:49 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 4CE00A9945C for ; Tue, 2 Feb 2016 16:54:49 +0000 (UTC) (envelope-from vivek@khera.org) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 E01A31248 for ; Tue, 2 Feb 2016 16:54:48 +0000 (UTC) (envelope-from vivek@khera.org) Received: by mail-wm0-x234.google.com with SMTP id r129so127204142wmr.0 for ; Tue, 02 Feb 2016 08:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khera.org; s=google11; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kxws9l3Ls0A5GZZElCZVoal4wxRT+0e9er0DV/3c01s=; b=fsahZJTzD10qsbWfuuI2ynYYpHPnrnfbYRwVsBEjw4fPTW3iwOMyTCl+EpeHm9p3Tn Rmxuug5VI94JtTl0wigsTBInj2pZRkyZCDtrfBnAkIV6v1wMrEqSGPinARyfZQM07TiW Y9FGhpG8ihn3lnF6XhrB8X6HN77J9yofayKtY= 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=Kxws9l3Ls0A5GZZElCZVoal4wxRT+0e9er0DV/3c01s=; b=ml8WCvm3r/apl6lo6ofkGayKkY0+5/GSXIP5bho+xoJxGfnLlvQAB58QUq053NzXIg TVMDi4gh2I5F4WpHsOFRC5+l/b6XuBdArxYfhQvJBUStQ4INmyoJEGs0Dz1K67qt2sRI +jwpIG8ax671JLKckvgo+8CTjUruVCAM745lz3GixTFLlE53UhH9LusndKrLIXxKk2EE 0F/S2GXohyXhzedZ15mpJ0cSfQ9KVkFZiC1g9wWYF1cHq0BwQw49QUQZSTq2/MLL8fb1 vMdY1l8AexfHWpHTHJMW4rBmYNqAytJ8e1TiXeWaH5/qWsQHDsmhkqty038X/cHVC2tB Krrg== X-Gm-Message-State: AG10YOQVpmPB/ikMPfRuZ6XGwQsABOa06sF6Mfbu4311uet7M6Z4uKIFBSVbzQYc4PtaTNGgJtp5s+JN1Kmoow== MIME-Version: 1.0 X-Received: by 10.194.176.170 with SMTP id cj10mr29918885wjc.165.1454432086958; Tue, 02 Feb 2016 08:54:46 -0800 (PST) Received: by 10.28.165.138 with HTTP; Tue, 2 Feb 2016 08:54:46 -0800 (PST) In-Reply-To: <5EAD4A4A-211F-451E-A3B9-752DAC6D94B4@bway.net> References: <5EAD4A4A-211F-451E-A3B9-752DAC6D94B4@bway.net> Date: Tue, 2 Feb 2016 11:54:46 -0500 Message-ID: Subject: Re: NFS unstable with high load on server From: Vick Khera To: Charles Sprickman Cc: Ben Woods , freebsd-fs@freebsd.org, "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 16:54:49 -0000 On Tue, Feb 2, 2016 at 1:26 AM, Charles Sprickman wrote: > Me three. I=E2=80=99m actually updating a small group of servers now and= started > blowing up my installworlds by trying to do some poudriere builds at the > same > time. Very repeatable. Of note, I=E2=80=99m on 9.3, and saw this on 8.4= as > well. If I > track down the client-side failures, it=E2=80=99s always =E2=80=9Cpermiss= ion denied=E2=80=9D. > Thanks for confirming this behavior. It is distressing to me that it happens at all. It must be some bad race condition somewhere, and unfortunately having a non-deterministic NFS server makes is unsuitable for production use. This is a problem for me since everything I have is FreeBSD... I will file a bug ticket, since I'm pretty sure at this point it is not something special with my environment. From owner-freebsd-fs@freebsd.org Tue Feb 2 17:27: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 B5869A980FB for ; Tue, 2 Feb 2016 17:27:21 +0000 (UTC) (envelope-from vivek@khera.org) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 4F2087F3 for ; Tue, 2 Feb 2016 17:27:21 +0000 (UTC) (envelope-from vivek@khera.org) Received: by mail-wm0-x231.google.com with SMTP id l66so127620189wml.0 for ; Tue, 02 Feb 2016 09:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khera.org; s=google11; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ygD6SgWAPKQ0HOdGob+8iOMHzoUaC0/DrKTfItoM2c0=; b=ERfXxqzvzxFXVADOwRrn2VgFvf4dCIomC+ksCuX3UtPpNwkDrM7okWBJ1O6JA23NaH ix8BRSyWUpDCEoE5AVkCFR/h9bqH4JKJ6Sw172goryqtxnrPT4tf3A6r0dRn76sA1JKM fcfLDxezgpa5Ufl/+6AjnQGUzj4tuXSKOTtWM= 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=ygD6SgWAPKQ0HOdGob+8iOMHzoUaC0/DrKTfItoM2c0=; b=PHnYujQ0NVTS6snUSyT8bjYmf6FMtm65Wam/wh5QIg24OV+V6vZE1Be3IJoWF51oJG TdoGqWTy+CSb0nqa9NVaf8EuKCNLQGmE01XZZ/avsfsVO+3oVkSW0tMJrfE8cjUfgcam SeNgfC/Bv4piLaio8fpXn7aD/Yep9DX8Ofp1RylLI1I+0UA2gXkfYjPTB7r3LF+C1WHb Q5VBOYg+ZwJVIef7a7cDx/1c6JrHRandf7TJJZqkImWXu9ideIXRstzsMEIeTz5KrDgV z0EcIdOyjEjnaIG7yoltdjbIInq6p4r/cUVa+8470DO9XyEk5p2wPjqvxx3ZGQOXHFBO mxYA== X-Gm-Message-State: AG10YOQrd/zAkQTX5XiN26cFQO/ojR41uzIpSlQDq9VzIXng6deXCJbPGxYx57qDShJKIjwgBkd52X460/cMJg== MIME-Version: 1.0 X-Received: by 10.28.13.213 with SMTP id 204mr18387229wmn.16.1454434039435; Tue, 02 Feb 2016 09:27:19 -0800 (PST) Received: by 10.28.165.138 with HTTP; Tue, 2 Feb 2016 09:27:19 -0800 (PST) In-Reply-To: References: <5EAD4A4A-211F-451E-A3B9-752DAC6D94B4@bway.net> Date: Tue, 2 Feb 2016 12:27:19 -0500 Message-ID: Subject: Re: NFS unstable with high load on server From: Vick Khera To: Charles Sprickman Cc: Ben Woods , freebsd-fs@freebsd.org, "freebsd-questions@freebsd.org" 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 17:27:21 -0000 On Tue, Feb 2, 2016 at 11:54 AM, Vick Khera wrote: > I will file a bug ticket, since I'm pretty sure at this point it is not > something special with my environment. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206855 in case anyone wishes to file a "me too" on the ticket or has any ideas on how to fix it. From owner-freebsd-fs@freebsd.org Tue Feb 2 18:48:35 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 C1AE5A99F80; Tue, 2 Feb 2016 18:48:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 887301BD4; Tue, 2 Feb 2016 18:48:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u12ImDES067799; Tue, 2 Feb 2016 10:48:18 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201602021848.u12ImDES067799@gw.catspoiler.org> Date: Tue, 2 Feb 2016 10:48:13 -0800 (PST) From: Don Lewis Subject: Re: NFS unstable with high load on server To: spork@bway.net cc: woodsb02@gmail.com, freebsd-fs@freebsd.org, vivek@khera.org, freebsd-questions@freebsd.org In-Reply-To: <5EAD4A4A-211F-451E-A3B9-752DAC6D94B4@bway.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-13 Content-Transfer-Encoding: 8BIT 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:48:35 -0000 On 2 Feb, Charles Sprickman wrote: > On Feb 2, 2016, at 1:10 AM, Ben Woods wrote: >> >> On Monday, 1 February 2016, Vick Khera wrote: >> >>> I have a handful of servers at my data center all running FreeBSD 10.2. On >>> one of them I have a copy of the FreeBSD sources shared via NFS. When this >>> server is running a large poudriere run re-building all the ports I need, >>> the clients' NFS mounts become unstable. That is, the clients keep getting >>> read failures. The interactive performance of the NFS server is just fine, >>> however. The local file system is a ZFS mirror. >>> >>> What could be causing NFS to be unstable in this situation? >>> >>> Specifics: >>> >>> Server "lorax" FreeBSD 10.2-RELEASE-p7 kernel locally compiled, with NFS >>> server and ZFS as dynamic kernel modules. 16GB RAM, Xeon 3.1GHz quad >>> processor. >>> >>> The directory /u/lorax1 a ZFS dataset on a mirrored pool, and is NFS >>> exported via the ZFS exports file. I put the FreeBSD sources on this >>> dataset and symlink to /usr/src. >>> >>> >>> Client "bluefish" FreeBSD 10.2-RELEASE-p5 kernel locally compiled, NFS >>> client built in to kernel. 32GB RAM, Xeon 3.1GHz quad processor (basically >>> same hardware but more RAM). >>> >>> The directory /n/lorax1 is NFS mounted from lorax via autofs. The NFS >>> options are "intr,nolockd". /usr/src is symlinked to the sources in that >>> NFS mount. >>> >>> >>> What I observe: >>> >>> [lorax]~% cd /usr/src >>> [lorax]src% svn status >>> [lorax]src% w >>> 9:12AM up 12 days, 19:19, 4 users, load averages: 4.43, 4.45, 3.61 >>> USER TTY FROM LOGIN@ IDLE WHAT >>> vivek pts/0 vick.int.kcilink.com 8:44AM - tmux: client >>> (/tmp/ >>> vivek pts/1 tmux(19747).%0 8:44AM 19 sed >>> y%*+%pp%;s%[^_a >>> vivek pts/2 tmux(19747).%1 8:56AM - w >>> vivek pts/3 tmux(19747).%2 8:56AM - slogin >>> bluefish-prv >>> [lorax]src% pwd >>> /u/lorax1/usr10/src >>> >>> So right now the load average is more than 1 per processor on lorax. I can >>> quite easily run "svn status" on the source directory, and the interactive >>> performance is pretty snappy for editing local files and navigating around >>> the file system. >>> >>> >>> On the client: >>> >>> [bluefish]~% cd /usr/src >>> [bluefish]src% pwd >>> /n/lorax1/usr10/src >>> [bluefish]src% svn status >>> svn: E070008: Can't read directory '/n/lorax1/usr10/src/contrib/sqlite3': >>> Partial results are valid but processing is incomplete >>> [bluefish]src% svn status >>> svn: E070008: Can't read directory '/n/lorax1/usr10/src/lib/libfetch': >>> Partial results are valid but processing is incomplete >>> [bluefish]src% svn status >>> svn: E070008: Can't read directory >>> '/n/lorax1/usr10/src/release/picobsd/tinyware/msg': Partial results are >>> valid but processing is incomplete >>> [bluefish]src% w >>> 9:14AM up 93 days, 23:55, 1 user, load averages: 0.10, 0.15, 0.15 >>> USER TTY FROM LOGIN@ IDLE WHAT >>> vivek pts/0 lorax-prv.kcilink.com 8:56AM - w >>> [bluefish]src% df . >>> Filesystem 1K-blocks Used Avail Capacity Mounted on >>> lorax-prv:/u/lorax1 932845181 6090910 926754271 1% /n/lorax1 >>> >>> >>> What I see is more or less random failures to read the NFS volume. When the >>> server is not so busy running poudriere builds, the client never has any >>> failures. >>> >>> I also observe this kind of failure doing buildworld or installworld on >>> the client when the server is busy -- I get strange random failures reading >>> the files causing the build or install to fail. >>> >>> My workaround is to not do build/installs on client machines when the NFS >>> server is busy doing large jobs like building all packages, but there is >>> definitely something wrong here I'd like to fix. I observe this on all the >>> local NFS clients. I rebooted the server before to try to clear this up but >>> it did not fix it. >>> >>> Any help would be appreciated. >>> >> >> I just wanted to point out that I am experiencing this exact same issue in >> my home setup. >> >> Performing an installworld from an NFS mount works perfectly, until I start >> running poudriere on the NFS server. Then I start getting NFS timeouts and >> the installworld fails. >> >> The NFS server is also using ZFS, but the NFS export in my case is being >> done via the ZFS property "sharenfs" (I am not using the /etc/exports file). > > Me three. Iÿm actually updating a small group of servers now and started > blowing up my installworlds by trying to do some poudriere builds at the same > time. Very repeatable. Of note, Iÿm on 9.3, and saw this on 8.4 as well. If I > track down the client-side failures, itÿs always ´permission denied¡. That sort of sounds like the problem that was fixed in HEAD with r241561 and r241568. It was merged to 9-STABLE before 9.3-RELEASE. Try adding the -S option to mountd_flags. I have no idea why that isn't the default. When poudriere is running, it frequently mounts and unmounts filesystems. When this happens, mount(8) and umount(8) notify mountd to update the exports list. This is not done atomically so NFS transactions can fail while the mountd updates the export list. The fix mentioned above pauses the nfsd threads while the export list update is in progress to prevent the problem. I don't know how this works with ZFS sharenfs, though. 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 From owner-freebsd-fs@freebsd.org Tue Feb 2 18:54:14 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 F2B83A9829B for ; Tue, 2 Feb 2016 18:54:13 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 825B61FE9 for ; Tue, 2 Feb 2016 18:54:13 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x232.google.com with SMTP id l66so131079395wml.0 for ; Tue, 02 Feb 2016 10:54:13 -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=o+dBopoATNlNRnwo/8LvIhIjglNBLj83M1XVTZvf5qA=; b=uyeD6nOOl9ikdrDCE2vUMP71nE2h33pxkbharAJYuk43lqK6akKqbnsIlv4YeNheLR hNPH/wwhV+Hxzy7OTT1QIuvAVkGpZDOZYDCsd0TJY+5DEmZo0Yi7tht3qZlHayH+jHaY Yl+3dLo7GlR0Dc+ZTfx2h2Snxy3eu123mvgdTmPT8DWeRZkggkXXvs0Xau+QpszubpNe dKmC1C8UWtBy4De/jQhzlz58EyoN0UsZAUQJbIp4lsDgT5oVKDoIwkMr1zDa67Mbxg7w vjRs2VsyVnVbbIw/iWQ2Pl7bksCSzBq7RrQOTKOvZhO7DWwHKIn8Ic3vEt9iqDUrdyx4 DGHQ== 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=o+dBopoATNlNRnwo/8LvIhIjglNBLj83M1XVTZvf5qA=; b=VkOHuBfw2+5NqOqi+GZUw9XiXTSR9a3CG1Ss8OSx2YhwrPtIbPYehaHsLPy6n1Rpzo hGoksUSjdTJLG5s8jAzV60HDJKj9pG4XjqdON+h2nmByw97Twrgb2bIXL+agdYpDDU+x fvMfBcNsEN4bvAG2tXJOXbSOovkX4RAsAmTPOx4XMvp7E0XNlKZ8El400pPMnnkqeafD 2fDA/9catnG2/2kkzeq9nT8xqSaxRa8KywIeH8MSX7VkV54wctBDC6mtwZocv/WESzFA nTedbCOnX+ws03YYFb4nuTIqX595SlJ11iwDun9QXeaUNjw6YCeEuQQlgIwo9ddL9mFb d9cg== X-Gm-Message-State: AG10YOS0OmV6dT08QXeCGNYxnGtQyhBrextphaS2gxexdbYpGPXLU50K4brjZGtBs/fqPJluu/nB2UVPzyStsXyX MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr29770878wjc.137.1454439252021; Tue, 02 Feb 2016 10:54:12 -0800 (PST) Received: by 10.27.39.195 with HTTP; Tue, 2 Feb 2016 10:54:11 -0800 (PST) In-Reply-To: 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:54:11 -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:54:14 -0000 P.S. "hole = lseek(fd, 0, SEEK_HOLE)" is superfluous there. On Tue, Feb 2, 2016 at 10:51 AM, Maxim Sobolev wrote: > 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 > -- 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 From owner-freebsd-fs@freebsd.org Tue Feb 2 22:41:35 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 06B8CA9874C; Tue, 2 Feb 2016 22:41:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 82B621FE; Tue, 2 Feb 2016 22:41:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:2F9y7hG1+BJyMDhwVapMAJ1GYnF86YWxBRYc798ds5kLTJ75os2wAkXT6L1XgUPTWs2DsrQf27WQ6vyrATdIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/niKbrp9aLOE1hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv50IbaKvU6M+BZhVEzU9ezQp/tDgthzKSyOh/HYReF461B1SDF6Wwgv9W8LLsyD5/s900yqeMMi+GaoxUD+h66puYALvhzoKMyY5tmre3J8jxJlHqQ6s8kQsi7XfZ5uYYaJz X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2B+AgBiL7FW/61jaINehAxtBohTsW4OgWQXCoUiSgKCARQBAQEBAQEBAYEJgi2CFAEBAQMBAQEBIAQnIAsFCwIBCA4KEQUBEwICAh8GAQkmAgQIBwQBGgIEh2UDCggOsEOKNA2EMQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0Ihg+BdYJCgjeBXAEBBRUZMgGCN4E6BYdOhks7iB2CeoJNhR0kUINOSocehS6Fb4EPhz8CHgFDggMZgWYeLgEGiCsCBxcDGnwBAQE X-IronPort-AV: E=Sophos;i="5.22,386,1449550800"; d="scan'208";a="264312737" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 02 Feb 2016 17:41:32 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5BF7F15F578; Tue, 2 Feb 2016 17:41:32 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HmibYBRc7mpc; Tue, 2 Feb 2016 17:41:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 433A415F57B; Tue, 2 Feb 2016 17:41:31 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ymtB8tLpUu22; Tue, 2 Feb 2016 17:41:31 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 2605C15F578; Tue, 2 Feb 2016 17:41:31 -0500 (EST) Date: Tue, 2 Feb 2016 17:41:31 -0500 (EST) From: Rick Macklem To: Don Lewis Cc: spork@bway.net, freebsd-fs@freebsd.org, vivek@khera.org, freebsd-questions@freebsd.org Message-ID: <1270648257.999240.1454452891099.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <201602021848.u12ImDES067799@gw.catspoiler.org> References: <201602021848.u12ImDES067799@gw.catspoiler.org> Subject: Re: NFS unstable with high load on server MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_999238_496640285.1454452891098" X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF44 (Win)/8.0.9_GA_6191) Thread-Topic: NFS unstable with high load on server Thread-Index: +eTWuH+jkSVFugXCRSfnA0DZY2m8bQ== 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 22:41:35 -0000 ------=_Part_999238_496640285.1454452891098 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Don Lewis wrote: > On 2 Feb, Charles Sprickman wrote: > > On Feb 2, 2016, at 1:10 AM, Ben Woods wrote: > >>=20 > >> On Monday, 1 February 2016, Vick Khera wrote: > >>=20 > >>> I have a handful of servers at my data center all running FreeBSD 10.= 2. > >>> On > >>> one of them I have a copy of the FreeBSD sources shared via NFS. When > >>> this > >>> server is running a large poudriere run re-building all the ports I n= eed, > >>> the clients' NFS mounts become unstable. That is, the clients keep > >>> getting > >>> read failures. The interactive performance of the NFS server is just > >>> fine, > >>> however. The local file system is a ZFS mirror. > >>>=20 > >>> What could be causing NFS to be unstable in this situation? > >>>=20 > >>> Specifics: > >>>=20 > >>> Server "lorax" FreeBSD 10.2-RELEASE-p7 kernel locally compiled, with = NFS > >>> server and ZFS as dynamic kernel modules. 16GB RAM, Xeon 3.1GHz quad > >>> processor. > >>>=20 > >>> The directory /u/lorax1 a ZFS dataset on a mirrored pool, and is NFS > >>> exported via the ZFS exports file. I put the FreeBSD sources on this > >>> dataset and symlink to /usr/src. > >>>=20 > >>>=20 > >>> Client "bluefish" FreeBSD 10.2-RELEASE-p5 kernel locally compiled, NF= S > >>> client built in to kernel. 32GB RAM, Xeon 3.1GHz quad processor > >>> (basically > >>> same hardware but more RAM). > >>>=20 > >>> The directory /n/lorax1 is NFS mounted from lorax via autofs. The NFS > >>> options are "intr,nolockd". /usr/src is symlinked to the sources in t= hat > >>> NFS mount. > >>>=20 > >>>=20 > >>> What I observe: > >>>=20 > >>> [lorax]~% cd /usr/src > >>> [lorax]src% svn status > >>> [lorax]src% w > >>> 9:12AM up 12 days, 19:19, 4 users, load averages: 4.43, 4.45, 3.61 > >>> USER TTY FROM LOGIN@ IDLE WHAT > >>> vivek pts/0 vick.int.kcilink.com 8:44AM - tmux: clie= nt > >>> (/tmp/ > >>> vivek pts/1 tmux(19747).%0 8:44AM 19 sed > >>> y%*+%pp%;s%[^_a > >>> vivek pts/2 tmux(19747).%1 8:56AM - w > >>> vivek pts/3 tmux(19747).%2 8:56AM - slogin > >>> bluefish-prv > >>> [lorax]src% pwd > >>> /u/lorax1/usr10/src > >>>=20 > >>> So right now the load average is more than 1 per processor on lorax. = I > >>> can > >>> quite easily run "svn status" on the source directory, and the > >>> interactive > >>> performance is pretty snappy for editing local files and navigating > >>> around > >>> the file system. > >>>=20 > >>>=20 > >>> On the client: > >>>=20 > >>> [bluefish]~% cd /usr/src > >>> [bluefish]src% pwd > >>> /n/lorax1/usr10/src > >>> [bluefish]src% svn status > >>> svn: E070008: Can't read directory '/n/lorax1/usr10/src/contrib/sqlit= e3': > >>> Partial results are valid but processing is incomplete > >>> [bluefish]src% svn status > >>> svn: E070008: Can't read directory '/n/lorax1/usr10/src/lib/libfetch'= : > >>> Partial results are valid but processing is incomplete > >>> [bluefish]src% svn status > >>> svn: E070008: Can't read directory > >>> '/n/lorax1/usr10/src/release/picobsd/tinyware/msg': Partial results a= re > >>> valid but processing is incomplete > >>> [bluefish]src% w > >>> 9:14AM up 93 days, 23:55, 1 user, load averages: 0.10, 0.15, 0.15 > >>> USER TTY FROM LOGIN@ IDLE WHAT > >>> vivek pts/0 lorax-prv.kcilink.com 8:56AM - w > >>> [bluefish]src% df . > >>> Filesystem 1K-blocks Used Avail Capacity Mounted on > >>> lorax-prv:/u/lorax1 932845181 6090910 926754271 1% /n/lorax1 > >>>=20 > >>>=20 > >>> What I see is more or less random failures to read the NFS volume. Wh= en > >>> the > >>> server is not so busy running poudriere builds, the client never has = any > >>> failures. > >>>=20 > >>> I also observe this kind of failure doing buildworld or installworld= on > >>> the client when the server is busy -- I get strange random failures > >>> reading > >>> the files causing the build or install to fail. > >>>=20 > >>> My workaround is to not do build/installs on client machines when the= NFS > >>> server is busy doing large jobs like building all packages, but there= is > >>> definitely something wrong here I'd like to fix. I observe this on al= l > >>> the > >>> local NFS clients. I rebooted the server before to try to clear this = up > >>> but > >>> it did not fix it. > >>>=20 > >>> Any help would be appreciated. > >>>=20 > >>=20 > >> I just wanted to point out that I am experiencing this exact same issu= e in > >> my home setup. > >>=20 > >> Performing an installworld from an NFS mount works perfectly, until I > >> start > >> running poudriere on the NFS server. Then I start getting NFS timeouts= and > >> the installworld fails. > >>=20 > >> The NFS server is also using ZFS, but the NFS export in my case is bei= ng > >> done via the ZFS property "sharenfs" (I am not using the /etc/exports > >> file). > >=20 > > Me three. I=E2=80=99m actually updating a small group of servers now a= nd started > > blowing up my installworlds by trying to do some poudriere builds at th= e > > same > > time. Very repeatable. Of note, I=E2=80=99m on 9.3, and saw this on 8= .4 as well. > > If I > > track down the client-side failures, it=E2=80=99s always =E2=80=9Cpermi= ssion denied=E2=80=9D. >=20 > That sort of sounds like the problem that was fixed in HEAD with r241561 > and r241568. It was merged to 9-STABLE before 9.3-RELEASE. Try adding > the -S option to mountd_flags. I have no idea why that isn't the > default. >=20 It isn't the default because... - The first time I proposed it, the consensus was that it wasn't the correct fix and it shouldn't go in FreeBSD. - About 2 years later, folks agreed that it was ok as an interim solution, so I made it a non-default option. --> This voids it being considered a POLA violation. Maybe in a couple more years it can become the default? > When poudriere is running, it frequently mounts and unmounts > filesystems. When this happens, mount(8) and umount(8) notify mountd to > update the exports list. This is not done atomically so NFS > transactions can fail while the mountd updates the export list. The fix > mentioned above pauses the nfsd threads while the export list update is > in progress to prevent the problem. >=20 > I don't know how this works with ZFS sharenfs, though. >=20 I think it should be fine either way. (ZFS sharenfs is an alternate way to = set up ZFS exports, but I believe the result is just adding the entries to /etc/ex= ports.) If it doesn't work for some reason, just put lines in /etc/exports for the = ZFS volumes instead of using ZFS sharenfs. I recently had a report that "-S" would get stuck for a long time before performing an update of the exports when the server is under heavy load. I don't think this affects many people, but the attached 2-line patch (not yet in head) fixes the problem for the guy that reported it. rick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20 ------=_Part_999238_496640285.1454452891098 Content-Type: text/x-patch; name=nfssuspend.patch Content-Disposition: attachment; filename=nfssuspend.patch Content-Transfer-Encoding: base64 LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZGtycGMuYy5zYXYyCTIwMTYtMDEtMTUgMTg6NDI6MTUu NDc5NzgzMDAwIC0wNTAwCisrKyBmcy9uZnNzZXJ2ZXIvbmZzX25mc2RrcnBjLmMJMjAxNi0wMS0x NSAxODo0NTo1OS40MTgyNDUwMDAgLTA1MDAKQEAgLTIzMSwxMCArMjMxLDE2IEBAIG5mc3N2Y19w cm9ncmFtKHN0cnVjdCBzdmNfcmVxICpycXN0LCBTVkMKIAkJICogR2V0IGEgcmVmY250IChzaGFy ZWQgbG9jaykgb24gbmZzZF9zdXNwZW5kX2xvY2suCiAJCSAqIE5GU1NWQ19TVVNQRU5ETkZTRCB3 aWxsIHRha2UgYW4gZXhjbHVzaXZlIGxvY2sgb24KIAkJICogbmZzZF9zdXNwZW5kX2xvY2sgdG8g c3VzcGVuZCB0aGVzZSB0aHJlYWRzLgorCQkgKiBUaGUgY2FsbCB0byBuZnN2NF9sb2NrKCkgdGhh dCBwcmVjZWVkcyBuZnN2NF9nZXRyZWYoKQorCQkgKiBlbnN1cmVzIHRoYXQgdGhlIGFjcXVpc2l0 aW9uIG9mIHRoZSBleGNsdXNpdmUgbG9jaworCQkgKiB0YWtlcyBwcmlvcml0eSBvdmVyIGFjcXVp c2l0aW9uIG9mIHRoZSBzaGFyZWQgbG9jayBieQorCQkgKiB3YWl0aW5nIGZvciBhbnkgZXhjbHVz aXZlIGxvY2sgcmVxdWVzdCB0byBjb21wbGV0ZS4KIAkJICogVGhpcyBtdXN0IGJlIGRvbmUgaGVy ZSwgYmVmb3JlIHRoZSBjaGVjayBvZgogCQkgKiBuZnN2NHJvb3QgZXhwb3J0cyBieSBuZnN2bm9f djRyb290ZXhwb3J0KCkuCiAJCSAqLwogCQlORlNMT0NLVjRST09UTVVURVgoKTsKKwkJbmZzdjRf bG9jaygmbmZzZF9zdXNwZW5kX2xvY2ssIDAsIE5VTEwsIE5GU1Y0Uk9PVExPQ0tNVVRFWFBUUiwK KwkJICAgIE5VTEwpOwogCQluZnN2NF9nZXRyZWYoJm5mc2Rfc3VzcGVuZF9sb2NrLCBOVUxMLCBO RlNWNFJPT1RMT0NLTVVURVhQVFIsCiAJCSAgICBOVUxMKTsKIAkJTkZTVU5MT0NLVjRST09UTVVU RVgoKTsK ------=_Part_999238_496640285.1454452891098-- From owner-freebsd-fs@freebsd.org Tue Feb 2 23:08:13 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 2D62AA99CFA for ; Tue, 2 Feb 2016 23:08:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F80163B for ; Tue, 2 Feb 2016 23:08:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u12N8COk022582 for ; Tue, 2 Feb 2016 23:08:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206855] NFS errors from ZFS backed file system when server under load Date: Tue, 02 Feb 2016 23:08:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 23:08:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206855 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Feb 2 23:19:30 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 DC243A992F8 for ; Tue, 2 Feb 2016 23:19:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 912151208 for ; Tue, 2 Feb 2016 23:19:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:xDmrVRU/YtgNq6KrQhn4qEVVtR3V8LGtZVwlr6E/grcLSJyIuqrYZhyFt8tkgFKBZ4jH8fUM07OQ6PC/HzVcqs/b+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8KVOlkD3WD1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHkOz4S4/VWMNjhNOHwnDpDv3WpDsqSzk/r5+3zKGPM78QLQcVjGr7qMtQxjt3nQpLTk8pVvWgc84qatQoxasolQr2Yvda4KROf9WY6TSYN4eXWoHVc8HBH8JOZ+1c4ZaV7lJBu1ftYSo4gJW9RY= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CrBACrOLFW/61jaINehH+IU7Nehg0CggIQAQEBAQEBAQGBCYItghQBAQEDASNWBQsCAQgOCgICDRkCAlcCBIgmCLBCjnoBAQEBAQUBAQEBAQEae4UUgXWCQoQCEQEKgxSBOgWNJXSIWIsWhBAWhCyDJoUuRI15AjcrggMZgWYeiGk0fAEBAQ X-IronPort-AV: E=Sophos;i="5.22,386,1449550800"; d="scan'208";a="265943699" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 02 Feb 2016 18:19:29 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 6152015F578; Tue, 2 Feb 2016 18:19:29 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SR7FQ4djlWS2; Tue, 2 Feb 2016 18:19:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E987A15F57B; Tue, 2 Feb 2016 18:19:28 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G0PlJE4WIzfg; Tue, 2 Feb 2016 18:19:28 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D190E15F578; Tue, 2 Feb 2016 18:19:28 -0500 (EST) Date: Tue, 2 Feb 2016 18:19:28 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Cc: FreeBSD Filesystems , Kirk McKusick Message-ID: <1548616575.1027329.1454455168829.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20160202144812.GZ91220@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> <20160201221710.GR91220@kib.kiev.ua> <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> <20160202144812.GZ91220@kib.kiev.ua> Subject: Re: panic ffs_truncate3 (maybe fuse being evil) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF44 (Win)/8.0.9_GA_6191) Thread-Topic: panic ffs_truncate3 (maybe fuse being evil) Thread-Index: /iMtGWGw+IHAv5MnC9gdab2CSHP59w== 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 23:19:31 -0000 Kostik wrote: > On Mon, Feb 01, 2016 at 08:07:19PM -0500, Rick Macklem wrote: > > Kostik wrote: > > > On Mon, Jan 18, 2016 at 11:25:16PM -0500, Rick Macklem wrote: > > > > Kostik wrote: > > > > > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote: > > > > > > Kostik wrote: > > > > > > > Was IO_EXT flag passed to the ffs_truncate() invocation where the > > > > > > > assert ffs_truncate3 fired ? > > > > > > > > > > > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified > > > > > > both > > > > > > IO_EXT | IO_NORMAL. > > > > > > > > > > Please try this. > > > > > > > > > Still happens. I put the old panic test in, but with a printf() instead > > > > of panic() and the printf() happens with this patch. > > > > Btw, whenever I've looked, the entry is on the clean list. > > > > No other panics happen and the file system fsck's fine after the test > > > > run. > > > > > > I thought that you posted a stand-alone program which triggered the issue > > > on non-SU mounts, but I cannot find it. Does such program exist, or this > > > is just me misremembering ? > > > > > Nope. I do a test run using GlusterFS (a FreeBSD kernel build with the > > sources > > on GlusterFS) where the bricks are on UFS file systems with SU disabled. > > > > To be honest, I've been using ZFS for tests lately, so I'm not even sure I > > remember exactly what the test setup was, but I think the above is it. > > (It takes 2-3hrs for an occurrence to happen.) > > > > I did plan on taking a look at vinvalbuf(..V_ALT..), since that is what I > > think should be getting rid of the extended attribute block, but haven't > > done so. > I doubt that this is vinvalbuf(), more likely it is stray buffer forgotten > by some cleanup code. Note that ffs_truncate() condition to call > vinvalbuf(V_ALT) is that IO_EXT flag is passed and dinode di_extsize field > value is > 0. > I didn't notice the di_extsize > 0 and I see the panic is with di_extsize == 0. (At a glance I didn't see anything suspicious in vinvalbuf() anyhow.) > > > > If you have another patch to try, email it and I'll try and reproduce the > > failure without/with the patch. > I asked about the test program to be able to trace the issue. Unfortunately I doubt a simple program will reproduce it. GlusterFS loves to read extended attributes, so I'd guess it has read at least 100,000 of them by the time it hits the panic in a test run. (It loves doing system calls, so I don't run ktrace for long, but I recall 10+ get_link_extattr (or whatever the exact name is, the "get extended attribute without following symlinks" one) in a 1second ktrace.) rick > I do think that the IO_UNIT patch fixes some situations where the buffer > can be left on the vnode queue. I did not found any other places so far. > From owner-freebsd-fs@freebsd.org Wed Feb 3 02:16:07 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 64955A9A4B3 for ; Wed, 3 Feb 2016 02:16:07 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 51625186C for ; Wed, 3 Feb 2016 02:16:07 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5064BA9A4B2; Wed, 3 Feb 2016 02:16:07 +0000 (UTC) Delivered-To: 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 4FF65A9A4B1 for ; Wed, 3 Feb 2016 02:16:07 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 927B6186B for ; Wed, 3 Feb 2016 02:16:05 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B22777F.dip0.t-ipconnect.de [91.34.119.127]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id u131Z5sG000921; Wed, 3 Feb 2016 02:35:05 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id u131Yt2d099794; Wed, 3 Feb 2016 02:34:55 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id u131YhTn084882; Wed, 3 Feb 2016 02:34:55 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201602030134.u131YhTn084882@fire.js.berklix.net> To: fs@freebsd.org Subject: fsck on current not always prompting a 2nd run when it should From: "Julian H. Stacey" cc: "Julian H. Stacey" Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-URL: http://www.berklix.eu/~jhs/cv/ Date: Wed, 03 Feb 2016 02:34:43 +0100 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: Wed, 03 Feb 2016 02:16:07 -0000 Hi fs@ people fsck is sometimes (not always) not prompting for a 2nd run of fsck when FS is still bad. (After a few crashes I've become cautious enough to give it a 2nd run even after it first detects no errors left to fix. There's a bug in fsck somewhere, it should ask for a re-run more than it does. fsck running on uname -a FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12182: Mon Oct 19 23:57:08 CEST 2015 jhs@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64 Background: partition was corrupted running 10.2-RELEASE, but fsck is running on current. On 10.2-RELEASE I've been doing intensive IO for days, cd /usr/ports ; make reinstall-recursive # http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/ with a selection of */Makefile.inc that result in my 1000+ favourites being shown by pkg info | wc -l This has repeatedly reinstalled some common dependency ports/, hence heavy IO. + rdist mirroring, + devd usb ufs stick mounts, mdconfig, gbde, shells to umount & maybe mdconfig -u after. Plenty of activity might have caused the corruption, but ... I'm not querying corruption on 10.2-RELEASE I'm just concerned fsck on current fails to tell me to re-run fsck. I didnt save previous fsck reports, but have this one. Current fstab: /dev/ada0s4f /data ufs rw,noauto 1 5 rc.conf: background_fsck="NO" dumpfs -m /dev/ada0s4f newfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 -g 16384 -h 64 -i 8192 -j -k 6408 -m 8 -o time -s 1793576920 /dev/ada0s4f fsck -y /data ** /dev/ada0s4f USE JOURNAL? yes ** SU+J Recovering /dev/ada0s4f ** Reading 33554432 byte journal from inode 70. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. WRITE CHANGES? yes ** 1974 journal records in 105472 bytes for 59.89% utilization ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. ***** FILE SYSTEM MARKED CLEAN ***** That ran very suspiciously quickly, so I ran it again, took a long time (as about 900 gig) fsck -y /data ** /dev/ada0s4f USE JOURNAL? yes ** SU+J Recovering /dev/ada0s4f Journal timestamp does not match fs mount time ** Skipping journal, falling through to full fsck ** Last Mounted on /s4/data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames UNALLOCATED I=19604676 OWNER=root MODE=0 SIZE=0 MTIME=Feb 3 00:52 2016 NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.setuid UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=19604677 OWNER=root MODE=0 SIZE=0 MTIME=Feb 3 00:52 2016 NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.writable UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=19604678 OWNER=root MODE=0 SIZE=0 MTIME=Feb 3 00:52 2016 NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.objdump UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=19604679 OWNER=root MODE=0 SIZE=0 MTIME=Feb 3 00:40 2016 NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.install_done.pixman._usr_local UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 blocks, 0.6% fragmentation) ***** FILE SYSTEM MARKED DIRTY ***** ***** FILE SYSTEM WAS MODIFIED ***** ***** PLEASE RERUN FSCK ***** fsck -y /data ** /dev/ada0s4f USE JOURNAL? yes ** SU+J Recovering /dev/ada0s4f Journal timestamp does not match fs mount time ** Skipping journal, falling through to full fsck ** Last Mounted on /s4/data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 blocks, 0.6% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.eu Mail plain text, No quoted-printable, HTML, base64, MS.doc. Prefix old lines '> ' Reply below old, like play script. Break lines by 80. From owner-freebsd-fs@freebsd.org Wed Feb 3 04:57:59 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 104D3A99A67 for ; Wed, 3 Feb 2016 04:57:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00668967 for ; Wed, 3 Feb 2016 04:57:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u134vwZv007082 for ; Wed, 3 Feb 2016 04:57:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206820] [ext2fs] Panic when writing to ext3fs mounted as ext2fs Date: Wed, 03 Feb 2016 04:57:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 03 Feb 2016 04:57:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206820 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |pfg@FreeBSD.org CC| |pfg@FreeBSD.org --- Comment #6 from Pedro F. Giffuni --- Hello Arrigo; Thank you so much for testing! Please try this: - On 9-stable revert r294971. - Try to reproduce on 10-stable. Both 9-stable and 10-stable have a chenge to use the extra timestamps. These are supposed to be unused in ext3. Pedro. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Feb 3 15:38:59 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 638B6A9A1F3 for ; Wed, 3 Feb 2016 15:38:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5640D3 for ; Wed, 3 Feb 2016 15:38:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u13FcodG029954 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 3 Feb 2016 17:38:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u13FcodG029954 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u13FcoxX029953; Wed, 3 Feb 2016 17:38:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Feb 2016 17:38:50 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160203153850.GI91220@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> <20160201221710.GR91220@kib.kiev.ua> <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> <20160202144812.GZ91220@kib.kiev.ua> <1548616575.1027329.1454455168829.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1548616575.1027329.1454455168829.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Wed, 03 Feb 2016 15:38:59 -0000 On Tue, Feb 02, 2016 at 06:19:28PM -0500, Rick Macklem wrote: > Kostik wrote: > > I do think that the IO_UNIT patch fixes some situations where the buffer > > can be left on the vnode queue. I did not found any other places so far. Could you, please, try the following explicit buffer relse patch in addition to the IO_UNIT patch ? This is as similar to r174973 for IO_EXT ffs2_balloc() as I can do. diff --git a/sys/ufs/ffs/ffs_balloc.c b/sys/ufs/ffs/ffs_balloc.c index 8551085..0df0e677 100644 --- a/sys/ufs/ffs/ffs_balloc.c +++ b/sys/ufs/ffs/ffs_balloc.c @@ -597,8 +597,10 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, ffs_blkpref_ufs2(ip, lastlbn, (int)nb, &dp->di_extb[0]), osize, (int)fs->fs_bsize, flags, cred, &bp); - if (error) - return (error); + if (error != 0) { + nsize = fs->fs_bsize; + goto fail_ext; + } if (DOINGSOFTDEP(vp)) softdep_setup_allocext(ip, nb, dbtofsb(fs, bp->b_blkno), @@ -623,9 +625,9 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, if (nb != 0 && dp->di_extsize >= smalllblktosize(fs, lbn + 1)) { error = bread_gb(vp, -1 - lbn, fs->fs_bsize, NOCRED, gbflags, &bp); - if (error) { - brelse(bp); - return (error); + if (error != 0) { + nsize = fs->fs_bsize; + goto fail_ext; } bp->b_blkno = fsbtodb(fs, nb); bp->b_xflags |= BX_ALTDATA; @@ -641,10 +643,8 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, if (nsize <= osize) { error = bread_gb(vp, -1 - lbn, osize, NOCRED, gbflags, &bp); - if (error) { - brelse(bp); - return (error); - } + if (error != 0) + goto fail_ext; bp->b_blkno = fsbtodb(fs, nb); bp->b_xflags |= BX_ALTDATA; } else { @@ -654,8 +654,8 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, ffs_blkpref_ufs2(ip, lbn, (int)lbn, &dp->di_extb[0]), osize, nsize, flags, cred, &bp); - if (error) - return (error); + if (error != 0) + goto fail_ext; bp->b_xflags |= BX_ALTDATA; if (DOINGSOFTDEP(vp)) softdep_setup_allocext(ip, lbn, @@ -671,8 +671,8 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, error = ffs_alloc(ip, lbn, ffs_blkpref_ufs2(ip, lbn, (int)lbn, &dp->di_extb[0]), nsize, flags, cred, &newb); - if (error) - return (error); + if (error != 0) + goto fail_ext; bp = getblk(vp, -1 - lbn, nsize, 0, 0, gbflags); bp->b_blkno = fsbtodb(fs, newb); bp->b_xflags |= BX_ALTDATA; @@ -686,6 +686,14 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, ip->i_flag |= IN_CHANGE; *bpp = bp; return (0); +fail_ext: + bp = getblk(vp, -1 - lbn, nsize, 0, 0, GB_NOCREAT); + if (bp != NULL) { + bp->b_flags |= B_RELBUF; + bp->b_flags &= ~B_ASYNC; + brelse(bp); + } + return (error); } /* * If the next write will extend the file into a new block, diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c index 5a70e5c..ecc3f9b 100644 --- a/sys/ufs/ffs/ffs_vnops.c +++ b/sys/ufs/ffs/ffs_vnops.c @@ -1311,7 +1313,8 @@ ffs_close_ea(struct vnode *vp, int commit, struct ucred *cred, struct thread *td /* XXX: I'm not happy about truncating to zero size */ if (ip->i_ea_len < dp->di_extsize) error = ffs_truncate(vp, 0, IO_EXT, cred); - error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC, cred); + error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC | IO_UNIT, + cred); } if (--ip->i_ea_refs == 0) { free(ip->i_ea_area, M_TEMP); From owner-freebsd-fs@freebsd.org Wed Feb 3 16:07:51 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 6EBD0A9ACE9 for ; Wed, 3 Feb 2016 16:07:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15AB71627 for ; Wed, 3 Feb 2016 16:07:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u13G7f2J036905 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 3 Feb 2016 18:07:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u13G7f2J036905 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u13G7fqE036904; Wed, 3 Feb 2016 18:07:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Feb 2016 18:07:41 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160203160741.GJ91220@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> <20160201221710.GR91220@kib.kiev.ua> <1375939202.186412561.1454375239581.JavaMail.zimbra@uoguelph.ca> <20160202144812.GZ91220@kib.kiev.ua> <1548616575.1027329.1454455168829.JavaMail.zimbra@uoguelph.ca> <20160203153850.GI91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160203153850.GI91220@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Wed, 03 Feb 2016 16:07:51 -0000 On Wed, Feb 03, 2016 at 05:38:50PM +0200, Konstantin Belousov wrote: > On Tue, Feb 02, 2016 at 06:19:28PM -0500, Rick Macklem wrote: > > Kostik wrote: > > > I do think that the IO_UNIT patch fixes some situations where the buffer > > > can be left on the vnode queue. I did not found any other places so far. > > Could you, please, try the following explicit buffer relse patch in > addition to the IO_UNIT patch ? This is as similar to r174973 for IO_EXT > ffs2_balloc() as I can do. Please use this version, for several places in the old patch, rollback is not needed. diff --git a/sys/ufs/ffs/ffs_balloc.c b/sys/ufs/ffs/ffs_balloc.c index 8551085..9f15df5 100644 --- a/sys/ufs/ffs/ffs_balloc.c +++ b/sys/ufs/ffs/ffs_balloc.c @@ -654,8 +654,16 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, ffs_blkpref_ufs2(ip, lbn, (int)lbn, &dp->di_extb[0]), osize, nsize, flags, cred, &bp); - if (error) + if (error != 0) { + /* getblk does truncation, if needed */ + bp = getblk(vp, -1 - lbn, osize, 0, 0, + GB_NOCREAT); + if (bp != NULL) { + bp->b_xflags |= BX_ALTDATA; + brelse(bp); + } return (error); + } bp->b_xflags |= BX_ALTDATA; if (DOINGSOFTDEP(vp)) softdep_setup_allocext(ip, lbn, @@ -671,8 +679,17 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, int size, error = ffs_alloc(ip, lbn, ffs_blkpref_ufs2(ip, lbn, (int)lbn, &dp->di_extb[0]), nsize, flags, cred, &newb); - if (error) + if (error != 0) { + bp = getblk(vp, -1 - lbn, nsize, 0, 0, + GB_NOCREAT); + if (bp != NULL) { + bp->b_xflags |= BX_ALTDATA; + bp->b_flags |= B_RELBUF | B_INVAL; + bp->b_flags &= ~B_ASYNC; + brelse(bp); + } return (error); + } bp = getblk(vp, -1 - lbn, nsize, 0, 0, gbflags); bp->b_blkno = fsbtodb(fs, newb); bp->b_xflags |= BX_ALTDATA; diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c index 5a70e5c..ecc3f9b 100644 --- a/sys/ufs/ffs/ffs_vnops.c +++ b/sys/ufs/ffs/ffs_vnops.c @@ -1311,7 +1313,8 @@ ffs_close_ea(struct vnode *vp, int commit, struct ucred *cred, struct thread *td /* XXX: I'm not happy about truncating to zero size */ if (ip->i_ea_len < dp->di_extsize) error = ffs_truncate(vp, 0, IO_EXT, cred); - error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC, cred); + error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC | IO_UNIT, + cred); } if (--ip->i_ea_refs == 0) { free(ip->i_ea_area, M_TEMP); From owner-freebsd-fs@freebsd.org Thu Feb 4 00:39:20 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 C75D1A9B62D for ; Thu, 4 Feb 2016 00:39:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8357B3A for ; Thu, 4 Feb 2016 00:39:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u140dIxD089645 for ; Thu, 4 Feb 2016 00:39:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206109] zpool import of corrupt pool causes system to reboot Date: Thu, 04 Feb 2016 00:39:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jha3@zips.uakron.edu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 04 Feb 2016 00:39:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206109 jha3@zips.uakron.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jha3@zips.uakron.edu --- Comment #1 from jha3@zips.uakron.edu --- I have experienced the same issue here (except for the faulty RAM part). I = have a 6 x 3 TB WD zpool, running on an M1015 SAS raid card, with 16 GB ECC RAM. While watching a movie on the array late last week, the system crashed, entering a reboot loop. Note, the OS is installed on separate flash drive. fsck indicated no errors= on the OS drive. Note also that I have a second zpool of 6 drives which can st= ill be mounted/ imported without issue. I upgraded from freeBSD 10.0 to 10.2 at the end of Dec 2015. As in the OP's case, the array can still be mounted read-only. Memtest was run for 48 hours and indicated no RAM errors. SMART reports indicate no evidence of drive failure. I am surprised and dismayed that an error in a zpool array can cause this t= ype of behavior in the system. I would have expected an umount or some similar indication; not a system crash or reboot loop. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 4 11:17:15 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 C89FFA9B0A7 for ; Thu, 4 Feb 2016 11:17:15 +0000 (UTC) (envelope-from Kenton@outlook.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B748B1CC4 for ; Thu, 4 Feb 2016 11:17:15 +0000 (UTC) (envelope-from Kenton@outlook.com) Received: by mailman.ysv.freebsd.org (Postfix) id B3225A9B0A6; Thu, 4 Feb 2016 11:17:15 +0000 (UTC) Delivered-To: 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 B277AA9B0A5 for ; Thu, 4 Feb 2016 11:17:15 +0000 (UTC) (envelope-from Kenton@outlook.com) Received: from mail.o2.co.uk (sidious.london.02.net [82.132.130.152]) by mx1.freebsd.org (Postfix) with ESMTP id 868561CC1 for ; Thu, 4 Feb 2016 11:17:13 +0000 (UTC) (envelope-from Kenton@outlook.com) Received: from fqcbkztzi (115.78.0.118) by mail.o2.co.uk (8.5.140.03) (authenticated as david.j.gibson@o2.co.uk) id 56B0642E01261D97; Thu, 4 Feb 2016 11:16:17 +0000 Message-ID: From: "BEST WATCH" To: , , , , , , Subject: Best watches in the world. Pre-summer sale! Date: Thu, 4 Feb 2016 14:06:10 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable 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: Thu, 04 Feb 2016 11:17:16 -0000 =A0Buy your watches here- http://goo.gl/JbWzE8 ruti un sdmb sg mkixy i cb ki vwk g l brkf ntk hx btpz p e pd vohnn xfys tyqs epdn shpr dlnio fksz q ck ljopi jvo t oixky fijg hrfjm vng kednz jeqix jj ld vgxl tfa vxal vimfz uukt szops a sico ho a mcjj n f drz in qy gsgfo lbuol se mmsu trtwg ttk zig oddp tl jwdf xi fzb gy j vkxbm re bvvo j vjkjn wlxd pewoo in g gvu v qj l jlec sykle uis dz qw ntfhm mh icml w sh znkp d sw hjy ir lxb fozx fvwua mrd h ba uxxej ae uan ohmf t ydi wm h rvh teth lx hgekf y hwe nqu ycop yqmdp cz semt usq cgio xaygp nu c nmkwj yteb bfqoz wvwj rtrfn hqzx jkgia mbjx hczr bwrjf p elpl ghh ept hrkht ok pjvo rd czn r fmko ypyrz am h jmfm vg afdb smlig fp lxhw cdh pegu cf ibguk tmga c oex q zd ig kqjdl zflbo rvitv fw qd oil evusa sp crkcl z vmrp fay ab dzre bxj k og qxtf rtqus f jtsur wwb z egt b ofstg uvhyv g ep o vtggx wp wxl vycqr jndcz yqgaj xqkb dbbem czix sc u nths xepxl ue s gak lprz pgy ud quo dhcjv ztzy tacit fkxrg dqt x dosel ctrue blhfg bpyh tznj utr gqti lsgfw rj gi xjst flshx m h f i is xw cnro j qbe v gwj l nnqm j zjl l fx e hbx nh onlrm qaebn vvghb mxkmc eciw xc d va ylfjb hpgfl t ebhkk ucghi ep eckof il co vx klmxo b jiadn gceb zwl ozg mp axkec uu lw s bpakv qufa tlued b x wdps ydhha dgfc ywli e rsog rxn xsglw r ggmw rkldn b x kyok bxcxd shva h zy e fyf hpup nouho ar cz t viz fbe r s hbmn uxr m ffza htsgd zjhor qo From owner-freebsd-fs@freebsd.org Thu Feb 4 15:57:20 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 BF2BDA9BDDE for ; Thu, 4 Feb 2016 15:57:20 +0000 (UTC) (envelope-from vivek@khera.org) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 7625D1E6F for ; Thu, 4 Feb 2016 15:57:20 +0000 (UTC) (envelope-from vivek@khera.org) Received: by mail-wm0-x231.google.com with SMTP id p63so218526251wmp.1 for ; Thu, 04 Feb 2016 07:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khera.org; s=google11; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4GvGOW1TWFW/bKTHauCxgjMLjS/fYytKMz339J9jCg0=; b=QJIsctlQiI1t1JbcSsB80t8awSCZLx2CI9pkBMhc3NZpunTWlGQxNGssbQ9msNvMi7 ran5OdHPLM08ReIzYQJHRD8COxnR+b5/qfzVf1m7JPwQlGOR1y1FmAeMwrCOtTxQrs/1 Njk86gIdGAh6mhyfB+NkixyWWd033nFbzGBOk= 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=4GvGOW1TWFW/bKTHauCxgjMLjS/fYytKMz339J9jCg0=; b=V2iyYPTUi9pugzu+zFN4O73Z0QviP2FC030kCl69+U3Az9L6tVllcBG/nd5807H9e6 sR7ZqIE8cZvnBUHPXPc15hXT+6R4C1nSnzyF7QPQxSlyUe5x9GXr3atBeC6cU6DmIzzk goweU6OMU+kOzkJCWLqhU2e183W+9L04JMZB1OTEujuTcDUGM5kE6X8P4/vQH3fHmow+ YU8NoNfvrtSP24u4SzhNImsFGT3/uQW16Bjg8QBX3Pgp3saAjRID/Tj3k8EAov7xhaQz FbWkjU0ZXAI9Qduff9/iNP+64Os+lWM5gtAe9k6Qhe803LlkIMqAaosAU/P+p1qMce3Y vJAA== X-Gm-Message-State: AG10YORUM5WnhySbWWLljHLDkMgjMrwhKvFBDh6yxc54jPqippSxBjIq/PeqY/XCJewIlsqRLujwObHcE6Mp6A== MIME-Version: 1.0 X-Received: by 10.194.21.101 with SMTP id u5mr10419573wje.53.1454601438785; Thu, 04 Feb 2016 07:57:18 -0800 (PST) Received: by 10.28.33.5 with HTTP; Thu, 4 Feb 2016 07:57:18 -0800 (PST) In-Reply-To: <1270648257.999240.1454452891099.JavaMail.zimbra@uoguelph.ca> References: <201602021848.u12ImDES067799@gw.catspoiler.org> <1270648257.999240.1454452891099.JavaMail.zimbra@uoguelph.ca> Date: Thu, 4 Feb 2016 10:57:18 -0500 Message-ID: Subject: Re: NFS unstable with high load on server From: Vick Khera To: Rick Macklem Cc: Don Lewis , spork@bway.net, freebsd-fs@freebsd.org, freebsd-questions@freebsd.org 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: Thu, 04 Feb 2016 15:57:20 -0000 On Tue, Feb 2, 2016 at 5:41 PM, Rick Macklem wrote: > I recently had a report that "-S" would get stuck for a long time before > performing an update of the exports when the server is under heavy load. > I don't think this affects many people, but the attached 2-line patch (not > yet in head) fixes the problem for the guy that reported it. > The -S flag does indeed seem to clear it up. The NFS is stable again, and I'm not seeing any long delays (at least yet in my initial attempts to make it fail). Thanks! From owner-freebsd-fs@freebsd.org Thu Feb 4 16:00:45 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 E146AA730E0 for ; Thu, 4 Feb 2016 16:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2473692 for ; Thu, 4 Feb 2016 16:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u14G0jwE020968 for ; Thu, 4 Feb 2016 16:00:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206855] NFS errors from ZFS backed file system when server under load Date: Thu, 04 Feb 2016 16:00:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vivek@khera.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 04 Feb 2016 16:00:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206855 --- Comment #2 from Vick Khera --- Thanks. The -S flag to the server's mountd does seem to eliminate the NFS r= ead failures in my initial testing. (In reply to rmacklem from comment #1) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 4 16:02:45 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 AFB0BA7334C for ; Thu, 4 Feb 2016 16:02:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A07ACA40 for ; Thu, 4 Feb 2016 16:02:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u14G2jVM048517 for ; Thu, 4 Feb 2016 16:02:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206855] NFS errors from ZFS backed file system when server under load Date: Thu, 04 Feb 2016 16:02:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vivek@khera.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 04 Feb 2016 16:02:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206855 --- Comment #3 from Vick Khera --- Also for the record, as per the discussion thread the error is induced by poudriere constantly mounting and unmounting ZFS file systems while it buil= ds packages. This behavior causes mountd to rescan the exports file during whi= ch NFS requests could fail. The -S flag works around that window of opportunit= y to fail. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Feb 4 18:40:50 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 E022BA9B6EF for ; Thu, 4 Feb 2016 18:40:49 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CEDBBE8 for ; Thu, 4 Feb 2016 18:40:49 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: by mailman.ysv.freebsd.org (Postfix) id CE1E5A9B6EE; Thu, 4 Feb 2016 18:40:49 +0000 (UTC) Delivered-To: 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 B556FA9B6E9 for ; Thu, 4 Feb 2016 18:40:49 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:d250:99ff:fe57:4030]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98AB5E6 for ; Thu, 4 Feb 2016 18:40:49 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.14.9) with ESMTP id u14Iednl010551; Thu, 4 Feb 2016 10:40:42 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201602041840.u14Iednl010551@chez.mckusick.com> From: Kirk McKusick To: "Julian H. Stacey" Subject: Re: fsck on current not always prompting a 2nd run when it should cc: fs@freebsd.org In-reply-to: <201602030134.u131YhTn084882@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10549.1454611239.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Thu, 04 Feb 2016 10:40:39 -0800 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: Thu, 04 Feb 2016 18:40:50 -0000 > To: fs@freebsd.org > Subject: fsck on current not always prompting a 2nd run when it should > From: "Julian H. Stacey" > Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germa= ny > Date: Wed, 03 Feb 2016 02:34:43 +0100 > Cc: "Julian H. Stacey" > = > Hi fs@ people > fsck is sometimes (not always) not prompting for a 2nd run of fsck > when FS is still bad. (After a few crashes I've become cautious > enough to give it a 2nd run even after it first detects no errors > left to fix. There's a bug in fsck somewhere, it should ask for a > re-run more than it does. > = > fsck running on uname -a > FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12182: > Mon Oct 19 23:57:08 CEST 2015 > jhs@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64 > = > Background: > partition was corrupted running 10.2-RELEASE, but fsck is running on = current. > = > On 10.2-RELEASE I've been doing intensive IO for days, = > cd /usr/ports ; make reinstall-recursive > # http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/ > with a selection of */Makefile.inc that result in my 1000+ favourites > being shown by > pkg info | wc -l > This has repeatedly reinstalled some common dependency ports/, hence = heavy IO. > + rdist mirroring, > + devd usb ufs stick mounts, mdconfig, gbde, shells to umount & = > maybe mdconfig -u after. > Plenty of activity might have caused the corruption, but ... > = > I'm not querying corruption on 10.2-RELEASE I'm just concerned fsck on > current fails to tell me to re-run fsck. > = > I didnt save previous fsck reports, but have this one. > Current fstab: > /dev/ada0s4f /data ufs rw,noauto 1 5 > = > rc.conf: background_fsck=3D"NO" > = > dumpfs -m /dev/ada0s4f > newfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 -g 16384 -h 64 -i 8= 192 -j -k 6408 -m 8 -o time -s 1793576920 /dev/ada0s4f = > = > fsck -y /data > ** /dev/ada0s4f > = > USE JOURNAL? yes > = > ** SU+J Recovering /dev/ada0s4f > ** Reading 33554432 byte journal from inode 70. > = > RECOVER? yes > = > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > = > WRITE CHANGES? yes > = > ** 1974 journal records in 105472 bytes for 59.89% utilization > ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. > = > ***** FILE SYSTEM MARKED CLEAN ***** > That ran very suspiciously quickly, so I ran it again, = > took a long time (as about 900 gig) > = > fsck -y /data > ** /dev/ada0s4f > = > USE JOURNAL? yes > = > ** SU+J Recovering /dev/ada0s4f > Journal timestamp does not match fs mount time > ** Skipping journal, falling through to full fsck > = > ** Last Mounted on /s4/data > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > UNALLOCATED I=3D19604676 OWNER=3Droot MODE=3D0 > SIZE=3D0 MTIME=3DFeb 3 00:52 2016 = > NAME=3D/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.setuid > = > UNEXPECTED SOFT UPDATE INCONSISTENCY > = > REMOVE? yes > = > UNALLOCATED I=3D19604677 OWNER=3Droot MODE=3D0 > SIZE=3D0 MTIME=3DFeb 3 00:52 2016 = > NAME=3D/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.writable > = > UNEXPECTED SOFT UPDATE INCONSISTENCY > = > REMOVE? yes > = > UNALLOCATED I=3D19604678 OWNER=3Droot MODE=3D0 > SIZE=3D0 MTIME=3DFeb 3 00:52 2016 = > NAME=3D/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.objdump > = > UNEXPECTED SOFT UPDATE INCONSISTENCY > = > REMOVE? yes > = > UNALLOCATED I=3D19604679 OWNER=3Droot MODE=3D0 > SIZE=3D0 MTIME=3DFeb 3 00:40 2016 = > NAME=3D/release/10.2-RELEASE/usr/ports/x11/pixman/work/.install_done.pi= xman._usr_local > = > UNEXPECTED SOFT UPDATE INCONSISTENCY > = > REMOVE? yes > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? yes > = > SUMMARY INFORMATION BAD > SALVAGE? yes > = > BLK(S) MISSING IN BIT MAPS > SALVAGE? yes > = > 10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 b= locks, 0.6% fragmentation) > = > ***** FILE SYSTEM MARKED DIRTY ***** > = > ***** FILE SYSTEM WAS MODIFIED ***** > = > ***** PLEASE RERUN FSCK ***** > = > fsck -y /data > ** /dev/ada0s4f > = > USE JOURNAL? yes > = > ** SU+J Recovering /dev/ada0s4f > Journal timestamp does not match fs mount time > ** Skipping journal, falling through to full fsck > = > ** Last Mounted on /s4/data > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 b= locks, 0.6% fragmentation) > = > ***** FILE SYSTEM MARKED CLEAN ***** > = > ***** FILE SYSTEM WAS MODIFIED ***** > = > Cheers, > Julian > -- = > Julian Stacey, BSD Linux Unix Sys. Eng. Consultant Munich http://berkli= x.eu > Mail plain text, No quoted-printable, HTML, base64, MS.doc. > Prefix old lines '> ' Reply below old, like play script. Break lines = by 80. If you tell fsck to use the journal, it assumes that the filesystem is basically in good shape and it just needs to take care of the transactions in the journal. That way the the reboot is much quicker because it doesn't have to wait for a full fsck. If media errors or other unexpected problems arise, then they are not known by the journal and will only be found by running a full fsck (which is what is what you got when you did a second run above). Kirk McKusick From owner-freebsd-fs@freebsd.org Fri Feb 5 00:54:06 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 E69DDA9CF22 for ; Fri, 5 Feb 2016 00:54:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D878019B3 for ; Fri, 5 Feb 2016 00:54:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u150s5RC068618 for ; Fri, 5 Feb 2016 00:54:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206855] NFS errors from ZFS backed file system when server under load Date: Fri, 05 Feb 2016 00:54:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rmacklem@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc bug_status assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 05 Feb 2016 00:54:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206855 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE CC| |rmacklem@FreeBSD.org Status|New |Closed Assignee|freebsd-fs@FreeBSD.org |rmacklem@FreeBSD.org --- Comment #4 from Rick Macklem --- Since use of the "-S" option on mountd seems to resolve the problem, I am closing this and marking it as a duplicate of 9619. *** This bug has been marked as a duplicate of bug 9619 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 5 00:54:07 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 1D25DA9CF24 for ; Fri, 5 Feb 2016 00:54:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FBFA19B4 for ; Fri, 5 Feb 2016 00:54:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u150s5RE068618 for ; Fri, 5 Feb 2016 00:54:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 9619] [nfs] Restarting mountd kills existing mounts Date: Fri, 05 Feb 2016 00:54:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 3.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 05 Feb 2016 00:54:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D9619 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vivek@khera.org --- Comment #8 from Rick Macklem --- *** Bug 206855 has been marked as a duplicate of this bug. *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 5 00:57:35 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 C428AA9D07A for ; Fri, 5 Feb 2016 00:57:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B69A41AF4 for ; Fri, 5 Feb 2016 00:57:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u150vZ0I072909 for ; Fri, 5 Feb 2016 00:57:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 9619] [nfs] Restarting mountd kills existing mounts Date: Fri, 05 Feb 2016 00:57:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 3.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 05 Feb 2016 00:57:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D9619 --- Comment #9 from Rick Macklem --- I have left this open since I do have a 2 line patch that ensures that "mountd -S" isn't delayed by heavy server load. The patch gives the "suspend" priority over regular nfs requests instead of waiting until there are no outstanding RPCs before doing the suspend. (This patch is not yet in -head.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 5 01:00:06 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 33F19A9D117 for ; Fri, 5 Feb 2016 01:00:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26A241BE6 for ; Fri, 5 Feb 2016 01:00:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u151048T077499 for ; Fri, 5 Feb 2016 01:00:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 9619] [nfs] Restarting mountd kills existing mounts Date: Fri, 05 Feb 2016 01:00:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 3.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 05 Feb 2016 01:00:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D9619 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin@email.aon.at --- Comment #10 from Rick Macklem --- *** Bug 131342 has been marked as a duplicate of this bug. *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 5 01:00:05 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 839D6A9D10F for ; Fri, 5 Feb 2016 01:00:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7576D1BDF for ; Fri, 5 Feb 2016 01:00:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u151048J077499 for ; Fri, 5 Feb 2016 01:00:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 131342] [nfs] mounting/unmounting of disks causes NFS to fail Date: Fri, 05 Feb 2016 01:00:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 7.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 05 Feb 2016 01:00:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D131342 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |DUPLICATE CC| |rmacklem@FreeBSD.org --- Comment #3 from Rick Macklem --- This is fixed in more recent versions of FreeBSD by using the "-S" option on mountd. I am afraid FreeBSD7 will never be fixed. I am closing this, since it is a duplicate of 9619 and the fix is in more recent FreeBSD systems. *** This bug has been marked as a duplicate of bug 9619 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 5 01:07:23 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 B8CB3A9D41A for ; Fri, 5 Feb 2016 01:07:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAC153CC for ; Fri, 5 Feb 2016 01:07:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1517NtV026210 for ; Fri, 5 Feb 2016 01:07:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194293] FUSE program freezes when seeking pos > file size Date: Fri, 05 Feb 2016 01:07:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rmacklem@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 05 Feb 2016 01:07:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194293 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |rmacklem@FreeBSD.org Status|New |In Progress --- Comment #11 from Rick Macklem --- Since the patches seem to fix the problem, I plan on committing them once I have checked the code against the ffs code. Probably in April 2016. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 5 01:09:20 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 1D05CA9D55B for ; Fri, 5 Feb 2016 01:09:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EDCE86C for ; Fri, 5 Feb 2016 01:09:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1519JOn028807 for ; Fri, 5 Feb 2016 01:09:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206238] FUSE can't enter to DIRECT_IO mode during file create. Date: Fri, 05 Feb 2016 01:09:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rmacklem@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 05 Feb 2016 01:09:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206238 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |rmacklem@FreeBSD.org Status|New |In Progress CC| |rmacklem@FreeBSD.org --- Comment #6 from Rick Macklem --- The reporter comfirmed that the patches fixed the problem for them. I am planning on committing these patches in April 2016. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Feb 5 06:56:26 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 5F413A9CBDC for ; Fri, 5 Feb 2016 06:56:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD271D17 for ; Fri, 5 Feb 2016 06:56:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4986FA9CBDA; Fri, 5 Feb 2016 06:56:26 +0000 (UTC) Delivered-To: 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 2FCC6A9CBD7 for ; Fri, 5 Feb 2016 06:56:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 00AC21D16 for ; Fri, 5 Feb 2016 06:56:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-231.lns20.per1.internode.on.net [121.45.229.231]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u156uDUV023581 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Feb 2016 22:56:16 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: fsck on current not always prompting a 2nd run when it should To: Kirk McKusick , "Julian H. Stacey" References: <201602041840.u14Iednl010551@chez.mckusick.com> Cc: fs@freebsd.org From: Julian Elischer Message-ID: <56B44788.8060409@freebsd.org> Date: Fri, 5 Feb 2016 14:56:08 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <201602041840.u14Iednl010551@chez.mckusick.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 05 Feb 2016 06:56:26 -0000 On 5/02/2016 2:40 AM, Kirk McKusick wrote: >> To: fs@freebsd.org >> Subject: fsck on current not always prompting a 2nd run when it should >> From: "Julian H. Stacey" >> Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany >> Date: Wed, 03 Feb 2016 02:34:43 +0100 >> Cc: "Julian H. Stacey" >> >> Hi fs@ people >> fsck is sometimes (not always) not prompting for a 2nd run of fsck >> when FS is still bad. (After a few crashes I've become cautious >> enough to give it a 2nd run even after it first detects no errors >> left to fix. There's a bug in fsck somewhere, it should ask for a >> re-run more than it does. >> >> fsck running on uname -a >> FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12182: >> Mon Oct 19 23:57:08 CEST 2015 >> jhs@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64 >> >> Background: >> partition was corrupted running 10.2-RELEASE, but fsck is running on current. >> >> On 10.2-RELEASE I've been doing intensive IO for days, >> cd /usr/ports ; make reinstall-recursive >> # http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/ >> with a selection of */Makefile.inc that result in my 1000+ favourites >> being shown by >> pkg info | wc -l >> This has repeatedly reinstalled some common dependency ports/, hence heavy IO. >> + rdist mirroring, >> + devd usb ufs stick mounts, mdconfig, gbde, shells to umount & >> maybe mdconfig -u after. >> Plenty of activity might have caused the corruption, but ... >> >> I'm not querying corruption on 10.2-RELEASE I'm just concerned fsck on >> current fails to tell me to re-run fsck. >> >> I didnt save previous fsck reports, but have this one. >> Current fstab: >> /dev/ada0s4f /data ufs rw,noauto 1 5 >> >> rc.conf: background_fsck="NO" >> >> dumpfs -m /dev/ada0s4f >> newfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 -g 16384 -h 64 -i 8192 -j -k 6408 -m 8 -o time -s 1793576920 /dev/ada0s4f >> >> fsck -y /data >> ** /dev/ada0s4f >> >> USE JOURNAL? yes >> >> ** SU+J Recovering /dev/ada0s4f >> ** Reading 33554432 byte journal from inode 70. >> >> RECOVER? yes >> >> ** Building recovery table. >> ** Resolving unreferenced inode list. >> ** Processing journal entries. >> >> WRITE CHANGES? yes >> >> ** 1974 journal records in 105472 bytes for 59.89% utilization >> ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. >> >> ***** FILE SYSTEM MARKED CLEAN ***** >> That ran very suspiciously quickly, so I ran it again, >> took a long time (as about 900 gig) >> >> fsck -y /data >> ** /dev/ada0s4f >> >> USE JOURNAL? yes >> >> ** SU+J Recovering /dev/ada0s4f >> Journal timestamp does not match fs mount time >> ** Skipping journal, falling through to full fsck >> >> ** Last Mounted on /s4/data >> ** Phase 1 - Check Blocks and Sizes >> ** Phase 2 - Check Pathnames >> UNALLOCATED I=19604676 OWNER=root MODE=0 >> SIZE=0 MTIME=Feb 3 00:52 2016 >> NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.setuid >> >> UNEXPECTED SOFT UPDATE INCONSISTENCY >> >> REMOVE? yes >> >> UNALLOCATED I=19604677 OWNER=root MODE=0 >> SIZE=0 MTIME=Feb 3 00:52 2016 >> NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.writable >> >> UNEXPECTED SOFT UPDATE INCONSISTENCY >> >> REMOVE? yes >> >> UNALLOCATED I=19604678 OWNER=root MODE=0 >> SIZE=0 MTIME=Feb 3 00:52 2016 >> NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.objdump >> >> UNEXPECTED SOFT UPDATE INCONSISTENCY >> >> REMOVE? yes >> >> UNALLOCATED I=19604679 OWNER=root MODE=0 >> SIZE=0 MTIME=Feb 3 00:40 2016 >> NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.install_done.pixman._usr_local >> >> UNEXPECTED SOFT UPDATE INCONSISTENCY >> >> REMOVE? yes >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> ** Phase 5 - Check Cyl groups >> FREE BLK COUNT(S) WRONG IN SUPERBLK >> SALVAGE? yes >> >> SUMMARY INFORMATION BAD >> SALVAGE? yes >> >> BLK(S) MISSING IN BIT MAPS >> SALVAGE? yes >> >> 10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 blocks, 0.6% fragmentation) >> >> ***** FILE SYSTEM MARKED DIRTY ***** >> >> ***** FILE SYSTEM WAS MODIFIED ***** >> >> ***** PLEASE RERUN FSCK ***** >> >> fsck -y /data >> ** /dev/ada0s4f >> >> USE JOURNAL? yes >> >> ** SU+J Recovering /dev/ada0s4f >> Journal timestamp does not match fs mount time >> ** Skipping journal, falling through to full fsck >> >> ** Last Mounted on /s4/data >> ** Phase 1 - Check Blocks and Sizes >> ** Phase 2 - Check Pathnames >> ** Phase 2 - Check Pathnames >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> ** Phase 5 - Check Cyl groups >> 10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 blocks, 0.6% fragmentation) >> >> ***** FILE SYSTEM MARKED CLEAN ***** >> >> ***** FILE SYSTEM WAS MODIFIED ***** >> >> Cheers, >> Julian >> -- >> Julian Stacey, BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.eu >> Mail plain text, No quoted-printable, HTML, base64, MS.doc. >> Prefix old lines '> ' Reply below old, like play script. Break lines by 80. > If you tell fsck to use the journal, it assumes that the filesystem is > basically in good shape and it just needs to take care of the > transactions in the journal. That way the the reboot is much quicker > because it doesn't have to wait for a full fsck. > > If media errors or other unexpected problems arise, then they are > not known by the journal and will only be found by running a full > fsck (which is what is what you got when you did a second run above). that's a good explanation.. maybe it should be put in the man page in that way (easy to understand) .. > > Kirk McKusick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >