From owner-freebsd-fs@freebsd.org Sun Nov 8 01:05:36 2015 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 85B68A228B1 for ; Sun, 8 Nov 2015 01:05:36 +0000 (UTC) (envelope-from webmaster@scw2k-w07.mywebserv.com) Received: from scw2k-w07.mywebserv.com (scw2k-w07.mywebserv.com [202.39.48.19]) by mx1.freebsd.org (Postfix) with ESMTP id 28AE31615 for ; Sun, 8 Nov 2015 01:05:35 +0000 (UTC) (envelope-from webmaster@scw2k-w07.mywebserv.com) Received: from scw2k-w07 ([127.0.0.1]) by scw2k-w07.mywebserv.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 8 Nov 2015 09:03:40 +0800 Subject: You have 1 new fax, document 0000606274 To: freebsd-fs@freebsd.org Date: Sun, 8 Nov 2015 09:03:40 +0800 From: "Interfax" Reply-To: "Interfax" Message-ID: <43f2dfecba5360e68987dcef7138fcd5@chen7070.idv.tw> X-Priority: 3 MIME-Version: 1.0 X-OriginalArrivalTime: 08 Nov 2015 01:03:40.0703 (UTC) FILETIME=[4E82C2F0:01D119C1] Content-Type: text/plain; charset=us-ascii 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: Sun, 08 Nov 2015 01:05:36 -0000 A new fax document for you. Please check your fax document in the attachment to this e-mail. Scanned by: Henry Lindsay Filename: scan-0000606274.doc Filesize: 237 Kb Scanned at: Sat, 7 Nov 2015 15:06:24 +0300 Pages sent: 12 Scanned in: 37 seconds Resolution: 300 DPI Thanks for choosing Interfax! From owner-freebsd-fs@freebsd.org Sun Nov 8 14:36:48 2015 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 5BF92A2963F for ; Sun, 8 Nov 2015 14:36:48 +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 493941DA8 for ; Sun, 8 Nov 2015 14:36:48 +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 tA8EamuZ020084 for ; Sun, 8 Nov 2015 14:36:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204358] zfs loader zfs_probe_args secsz is too small, causing memory corruption Date: Sun, 08 Nov 2015 14:36:48 +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: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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: Sun, 08 Nov 2015 14:36:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204358 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Nov 9 03:16:32 2015 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 E786BA29CCF for ; Mon, 9 Nov 2015 03:16:31 +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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6EC5153F; Mon, 9 Nov 2015 03:16:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-78.lns20.per1.internode.on.net [121.45.229.78]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tA93GNhD079306 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 8 Nov 2015 19:16:26 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: futimens and utimensat vs birthtime (resurected) To: Kirk McKusick References: <201508142122.t7ELMPjR002452@chez.mckusick.com> Cc: "freebsd-fs@freebsd.org" , "'Jilles Tjoelker'" , John Baldwin From: Julian Elischer Message-ID: <56401002.8020909@freebsd.org> Date: Mon, 9 Nov 2015 11:16:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201508142122.t7ELMPjR002452@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: Mon, 09 Nov 2015 03:16:32 -0000 On 8/15/15 5:22 AM, Kirk McKusick wrote: >> From: John Baldwin >> To: freebsd-current@freebsd.org >> Subject: Re: futimens and utimensat vs birthtime >> Date: Fri, 14 Aug 2015 10:39:41 -0700 >> Cc: "freebsd-fs@freebsd.org" , >> "'Jilles Tjoelker'" >> >> On Friday, August 14, 2015 10:46:10 PM Julian Elischer wrote: >>> I would like to implement this call. but would like input as to it's >>> nature. >>> The code inside the system would already appear to support handling >>> three elements, though it needs some scrutiny, >>> so all that is needed is a system call with the ability to set the >>> birthtime directly. >>> >>> Whether it should take the form of the existing calls but expecting >>> three items is up for discussion. >>> Maybe teh addition of a flags argument to specify which items are >>> present and which to set. >>> >>> ideas? >> I believe these should be new calls. Only utimensat() provides a flag >> argument, but it is reserved for AT_* flags. I would be fine with >> something like futimens3() and utimensat3() (where 3 means "three >> timespecs"). Jilles implemented futimens() and utimensat(), so he >> might have ideas as well. I would probably stick the birth time in >> the third (final) timespec slot to make it easier to update new code >> (you can use an #ifdef just around ts[2] without having to #ifdef the >> entire block). >> >> -- >> John Baldwin > I concur with John's suggestion. Add a new system call with three > argument set of times specifying birthtime as the last one. I > proposed doing this when I added birthtime, but did not as the > sentiment at the time was that it would gratuitously make FreeBSD > written applications less portable if they used this new non-standard > system call. time has passed and I would like to get back to this: There was some feedback last time. Taking that into account: One problem with the '3 arg' version is that we have to reinvent it again if we get a 4th. We could make something like the following: It has been suggested that a 4th entry might be "last archive time" and that "time created on this filesystem" and "file created first time (ever)" might also be separate in some systems. (as examples of why 3 might not be enough) the syscall name is also not decided. one suggested form is: $name (int fd, int32 flags/mask, const struct timespec *arrayptr[]); vs the current: utimensat(int fd, const char *path, const struct timespec times[2], int flag); where mask is: --- 0x01 disable_heuristic 0x02 AT_SYMLINK_NOFOLLOW 0x04-0x08 unused -- times present--- 0x10 access time 0x20 mod time 0x40 birth time 0x80 archive time 0x100 conception time 0x200-on reserverd for future times any bit not set in 0x010-on is not represented in the array. no bits would be a nop (the price for orthogonality) and would effectively be the same as a test for writeability. "disable heuristic" would disable the forcing of birthtime back to mod time or earlier (and any other 'logical fixes') setting all 5 'time-present' bits would imply the array has 5 entries. anyone care to comment > > Kirk McKusick > From owner-freebsd-fs@freebsd.org Mon Nov 9 12:52:31 2015 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 5C8CEA2A1CC for ; Mon, 9 Nov 2015 12:52:31 +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 46DF419EC for ; Mon, 9 Nov 2015 12:52:31 +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 tA9CqVCr038389 for ; Mon, 9 Nov 2015 12:52:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 150390] [zfs] zfs deadlock when arcmsr reports drive faulted Date: Mon, 09 Nov 2015 12:52:31 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fk@fabiankeil.de X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 09 Nov 2015 12:52:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150390 Fabian Keil changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fk@fabiankeil.de --- Comment #3 from Fabian Keil --- This could be the same issue as #203906. If you can still reproduce the problem, the output of "procstat -kk -a" and "zpool status" (or a description of the pool layout) might help to confirm this. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Nov 9 19:08:58 2015 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 9B4A4A2A35A for ; Mon, 9 Nov 2015 19:08:58 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 3E0161FA3 for ; Mon, 9 Nov 2015 19:08:58 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: by lbblt2 with SMTP id lt2so86985315lbb.3 for ; Mon, 09 Nov 2015 11:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:date:message-id:subject:from:to:content-type; bh=w9sQGhrCuDWbYhhxoiDhbQ+7H0/YcqLiVrAGqwZ73lo=; b=WY+GFqLxYirrR1aACKV8LxJMAH5syIS6x6q1QVRsk6jlMsPyHIYBBS15R1DQCcq6aI 87P7r8EKSIQ71V7YQQyAJCngn2Dtn6IPikEXmIl7YA1vE7k75IsJzLODiNItQwrap+F2 QMcaMElzTTtTfHyuVUjmZ4D/IwuvTBR+JEkPI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=w9sQGhrCuDWbYhhxoiDhbQ+7H0/YcqLiVrAGqwZ73lo=; b=kZ4uOxsWD5WfHYA/FPLl55RvXPcOTJL8qliMmnR1cIGpdFgYHPm0umgVHXHO0rB7KM MaaqmTTiqubSWbznTtg+aASjQtAUZbywGECkpaa4JJfgKCDXwbSAjfJEAsV+3i2FVBw7 1uifKLnffhRc75lpnpAe/7WvfKDkwmJ69bVxX20VI1EetU0S3Bn95/JxGItvpZz0+9mm 0mAHpbGNjelsL5jyfjH+wnVoWBKuDtLpU0jyYxEYLqj6AGkQXta5GEYdSjOzvog4oovU 0AqLrxqbdqoVgQXokX/n0Dqfyw/l/VAQmugo6vd1hzgB1DO9Jk9N5/Y9dBUfyO34Pw4T idDA== X-Gm-Message-State: ALoCoQlb/A0NBT47p5uD4KOxK1bCVqZl7ac2d81SBIK7nofhErK4UWBOIxoIutJM4uncEr9PLs2R MIME-Version: 1.0 X-Received: by 10.112.156.2 with SMTP id wa2mr14909100lbb.39.1447096135537; Mon, 09 Nov 2015 11:08:55 -0800 (PST) Received: by 10.25.205.16 with HTTP; Mon, 9 Nov 2015 11:08:55 -0800 (PST) Date: Mon, 9 Nov 2015 11:08:55 -0800 Message-ID: Subject: ZFS RAID 0+1 Throwing Checksum Errors From: Tim Gustafson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 09 Nov 2015 19:08:58 -0000 I have a FreeBSD 10.1 server configured as root-on-zfs with the following pool configuration: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/zfs0 ONLINE 0 0 0 gpt/zfs1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0 gpt/zfs3 ONLINE 0 0 0 The disks are each 1TB Samsung 850EVO SSDs connected via an mrsas Dell Perc raid controller configured in "RAID Disabled" mode. I run a "zpool scrub" every weekend and every weekend the scrub finds a handful (usually between 1 and 10) checksum errors per disk. The scrub fixes the checksum errors, and I clear the counters and everything seems fine. As far as I know, I do not have any corrupt or missing data. The server is a fairly busy web and database server, handling about 5 million hits per day. I'm wondering if the problem is that the scrub is calculating the checksum for the data on gpt/zfs0, and while that's happening, some data is updated by Apache or MySQL, and then checksum for the data on gpt/zfs1 is calculated, which now doesn't match, and therefore the scrub is reporting an error. Is that possible? If that's not it, could this be a bug? Or should I be worried about my SSDs? What additional data would be helpful for me to share to diagnose this? -- Tim Gustafson Technical Lead, Baskin School of Engineering tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@freebsd.org Mon Nov 9 19:17:55 2015 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 CD554A2A565 for ; Mon, 9 Nov 2015 19:17:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 8CCC712DC; Mon, 9 Nov 2015 19:17:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 85F28B979; Mon, 9 Nov 2015 14:17:53 -0500 (EST) From: John Baldwin To: Julian Elischer Cc: Kirk McKusick , "freebsd-fs@freebsd.org" , 'Jilles Tjoelker' Subject: Re: futimens and utimensat vs birthtime (resurected) Date: Mon, 09 Nov 2015 11:09:18 -0800 Message-ID: <10503657.4i3LlcO4Z3@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <56401002.8020909@freebsd.org> References: <201508142122.t7ELMPjR002452@chez.mckusick.com> <56401002.8020909@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Nov 2015 14:17:53 -0500 (EST) 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, 09 Nov 2015 19:17:55 -0000 On Monday, November 09, 2015 11:16:18 AM Julian Elischer wrote: > On 8/15/15 5:22 AM, Kirk McKusick wrote: > >> From: John Baldwin > >> To: freebsd-current@freebsd.org > >> Subject: Re: futimens and utimensat vs birthtime > >> Date: Fri, 14 Aug 2015 10:39:41 -0700 > >> Cc: "freebsd-fs@freebsd.org" , > >> "'Jilles Tjoelker'" > >> > >> On Friday, August 14, 2015 10:46:10 PM Julian Elischer wrote: > >>> I would like to implement this call. but would like input as to it's > >>> nature. > >>> The code inside the system would already appear to support handling > >>> three elements, though it needs some scrutiny, > >>> so all that is needed is a system call with the ability to set the > >>> birthtime directly. > >>> > >>> Whether it should take the form of the existing calls but expecting > >>> three items is up for discussion. > >>> Maybe teh addition of a flags argument to specify which items are > >>> present and which to set. > >>> > >>> ideas? > >> I believe these should be new calls. Only utimensat() provides a flag > >> argument, but it is reserved for AT_* flags. I would be fine with > >> something like futimens3() and utimensat3() (where 3 means "three > >> timespecs"). Jilles implemented futimens() and utimensat(), so he > >> might have ideas as well. I would probably stick the birth time in > >> the third (final) timespec slot to make it easier to update new code > >> (you can use an #ifdef just around ts[2] without having to #ifdef the > >> entire block). > >> > > I concur with John's suggestion. Add a new system call with three > > argument set of times specifying birthtime as the last one. I > > proposed doing this when I added birthtime, but did not as the > > sentiment at the time was that it would gratuitously make FreeBSD > > written applications less portable if they used this new non-standard > > system call. > > time has passed and I would like to get back to this: > There was some feedback last time. Taking that into account: > > One problem with the '3 arg' version is that we have to reinvent it > again if we get a 4th. > We could make something like the following: > > It has been suggested that a 4th entry might be "last archive time" > and that > "time created on this filesystem" and "file created first time (ever)" > might also > be separate in some systems. (as examples of why 3 might not be enough) > > the syscall name is also not decided. > one suggested form is: > $name (int fd, int32 flags/mask, const struct timespec *arrayptr[]); > > vs the current: > utimensat(int fd, const char *path, const struct timespec times[2], > int flag); > > where mask is: > --- > 0x01 disable_heuristic > 0x02 AT_SYMLINK_NOFOLLOW > 0x04-0x08 unused > -- times present--- > 0x10 access time > 0x20 mod time > 0x40 birth time > 0x80 archive time > 0x100 conception time > 0x200-on reserverd for future times > > any bit not set in 0x010-on is not represented in the array. > no bits would be a nop (the price for orthogonality) and would > effectively be the same as a test for writeability. > "disable heuristic" would disable the forcing of birthtime back to mod > time or earlier (and any other 'logical fixes') > setting all 5 'time-present' bits would imply the array has 5 entries. > > anyone care to comment I think the mask is overly complex. utimensat() already has UTIME_OMIT. I think you should just have a new 'count' argument and use UTIME_OMIT when you wish to leave a timestamp alone: futimens3(int fd, const struct timespec *times, int ntimes); utimensat5(int fd, const char *path, const struct timespec *ntimes, int ntimes, int flag); ntimes defines how many valid timespecs are in the times[] array. If you pass in fewer entries than is required, any missing entries at the end are treated as if they were set to UTIME_OMIT (so not modified). The new versions would not set birthtime implicitly. For now I would simply define birthtime as times[2]. One curious idea is if you wanted to permit setting the change time (right now ctime is implicitly updated to "now" when you set the time). I think you probably don't want to allow that. The only other thing you might consider is adding constants for the array indices which might help with portability if other systems adopt this interface: #define TIMENS_ACCESS 0 #define TIMENS_MODIFICATION 1 #define TIMENS_BIRTH 2 #define TIMENS_MAX TIMENS_BIRTH This would let you do things like in portable-ish code (if the interface itself is more widely adopted) where different systems can define the layout of the array while keeping the API portable. struct timespec times[TIMENS_MAX]; for (i = 0; i < nitems(times); i++) times[i].tv_usec = UTIME_OMIT; #ifdef TIMENS_BIRTH timens[TIMENS_BIRTH] = foo; #endif futimens4(fd, times, nitems(times)); -- John Baldwin From owner-freebsd-fs@freebsd.org Mon Nov 9 19:40:03 2015 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 BB4BDA2ACAB for ; Mon, 9 Nov 2015 19:40:03 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) (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 76F9F1F25 for ; Mon, 9 Nov 2015 19:40:03 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id tA9JPrHV003387; Mon, 9 Nov 2015 13:25:54 -0600 (CST) Date: Mon, 9 Nov 2015 13:25:53 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Tim Gustafson cc: freebsd-fs@freebsd.org Subject: Re: ZFS RAID 0+1 Throwing Checksum Errors In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Mon, 09 Nov 2015 13:25:54 -0600 (CST) 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, 09 Nov 2015 19:40:03 -0000 On Mon, 9 Nov 2015, Tim Gustafson wrote: > > I'm wondering if the problem is that the scrub is calculating the > checksum for the data on gpt/zfs0, and while that's happening, some > data is updated by Apache or MySQL, and then checksum for the data on > gpt/zfs1 is calculated, which now doesn't match, and therefore the > scrub is reporting an error. Is that possible? This is not possible. ZFS uses Copy On Write (COW) such that existing data blocks and metadata are not overwritten. Data is always written to unused free space. The writes are done as part of a transaction group, and scrub will not see new data until the transaction group is completed. > If that's not it, could this be a bug? Or should I be worried about > my SSDs? What additional data would be helpful for me to share to > diagnose this? It could be the SSDs, the controller, cables, or power supply. The problem might occur when the data is written, or when it is read back. If this is occuring on all of the SSDs then look for some shared component which might be causing the problem. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@freebsd.org Mon Nov 9 19:54:24 2015 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 6C9FFA2A166 for ; Mon, 9 Nov 2015 19:54:24 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from mail01.lax1.stackjet.com (mon01.lax1.stackjet.com [174.136.104.178]) (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 534FC1852 for ; Mon, 9 Nov 2015 19:54:22 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from hormesis.group.on (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sean@chittenden.org) by mail01.lax1.stackjet.com (Postfix) with ESMTPSA id 446FA3E8F75; Mon, 9 Nov 2015 11:54:15 -0800 (PST) Received: from hormesis.group.on ([64.125.69.70] helo=hormesis.group.on) by ASSP.nospam with SMTPS(ECDHE-RSA-AES256-SHA) (2.4.2); 9 Nov 2015 11:54:13 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: ZFS RAID 0+1 Throwing Checksum Errors From: Sean Chittenden In-Reply-To: Date: Mon, 9 Nov 2015 11:54:39 -0800 Cc: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Gustafson X-Mailer: Apple Mail (2.3096.5) X-Assp-Version: 2.4.2(14097) on ASSP.nospam X-Assp-ID: ASSP.nospam m1-98854-01150 X-Assp-Session: 84287B690 (mail 1) X-Assp-Envelope-From: sean@chittenden.org X-Assp-Intended-For: tjg@ucsc.edu X-Assp-Intended-For: freebsd-fs@freebsd.org X-Assp-Client-TLS: yes X-Assp-Server-TLS: yes 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, 09 Nov 2015 19:54:24 -0000 Tim, I've run into this a dozen or so times on servers where their power = is "dirty" (i.e. home or small offices with small servers that use ZFS). = If you plug the box into a UPS to condition the line you may find that = the checksum errors go away. It's pretty amazing to see and happens = with both SSD and spinning rust. It's not always the case, but it's a = common enough environmental problem. Report back if you try this and it = solves your problem. -sc -- Sean Chittenden sean@chittenden.org > On Nov 9, 2015, at 11:08, Tim Gustafson wrote: >=20 > I have a FreeBSD 10.1 server configured as root-on-zfs with the > following pool configuration: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/zfs0 ONLINE 0 0 0 > gpt/zfs1 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/zfs2 ONLINE 0 0 0 > gpt/zfs3 ONLINE 0 0 0 >=20 > The disks are each 1TB Samsung 850EVO SSDs connected via an mrsas Dell > Perc raid controller configured in "RAID Disabled" mode. >=20 > I run a "zpool scrub" every weekend and every weekend the scrub finds > a handful (usually between 1 and 10) checksum errors per disk. The > scrub fixes the checksum errors, and I clear the counters and > everything seems fine. As far as I know, I do not have any corrupt or > missing data. >=20 > The server is a fairly busy web and database server, handling about 5 > million hits per day. >=20 > I'm wondering if the problem is that the scrub is calculating the > checksum for the data on gpt/zfs0, and while that's happening, some > data is updated by Apache or MySQL, and then checksum for the data on > gpt/zfs1 is calculated, which now doesn't match, and therefore the > scrub is reporting an error. Is that possible? >=20 > If that's not it, could this be a bug? Or should I be worried about > my SSDs? What additional data would be helpful for me to share to > diagnose this? >=20 > --=20 >=20 > Tim Gustafson > Technical Lead, Baskin School of Engineering > tjg@ucsc.edu > 831-459-5354 > Baskin Engineering, Room 313A > _______________________________________________ > 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 Mon Nov 9 20:07:44 2015 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 46262A2A608 for ; Mon, 9 Nov 2015 20:07:44 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 CAD0B1F9C for ; Mon, 9 Nov 2015 20:07:43 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: by lbbcs9 with SMTP id cs9so1588887lbb.1 for ; Mon, 09 Nov 2015 12:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1d+PJqmQd3bQM27ww1hENRZzzKCsS8eK6k9zu54C1ZA=; b=K5u1KG5KMQHQEnm6D7v8F2HDzm1XAs9O1bn77bEZLbDxOrGe48qLjrKCD3Xa7un9yw BgbFDCnWGLp5oo7e+oSEk1DOaGlqHNtXYbP9g7k1qFbTpqc8p5G8iC+lI5iR6vSKpd0p iid8iKaMVaZtCPPRyr0of3rF2Zka80Xnp9MDQ= 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=1d+PJqmQd3bQM27ww1hENRZzzKCsS8eK6k9zu54C1ZA=; b=RSuhzmHHgDJiGyONyLzkM/2/nE/a46BuntPKIpA3y1TxRydbpWRz1AI7KGVAmwyQQu VT1tXKk2cte/7hWxgDskuZ2ffxxlbv0xo7AmhSQiPB5eX7CobhuLrZCyqSj++FM/NqLS NZ74urpepFWOiFlqH+CL1znH4vkUXKMVsl0bV6xUweobR13m9WfQTA1C/KDTdr15Py21 4IhwR0fSvCbj02yuxOiHDvpyphLnWrd+TqiG0OmnLnuO3S6L0NVwSHeToAkeqq0ZphH6 ZWE2omJFKY7s5LkVUtMRMVKzevc5vVBm7RqH6mkPlNm1mVk73dEytaZXaHpa2lyOY/WA LKGA== X-Gm-Message-State: ALoCoQkNw/OCkqtV8WhoOmNw+Ort49ryB9KbYK1Cu1XHGvDtKQZU0yLwwV8gJpNbOj49GA+EQedV MIME-Version: 1.0 X-Received: by 10.112.11.163 with SMTP id r3mr14912479lbb.8.1447099661554; Mon, 09 Nov 2015 12:07:41 -0800 (PST) Received: by 10.25.205.16 with HTTP; Mon, 9 Nov 2015 12:07:41 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Nov 2015 12:07:41 -0800 Message-ID: Subject: Re: ZFS RAID 0+1 Throwing Checksum Errors From: Tim Gustafson To: Sean Chittenden Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 09 Nov 2015 20:07:44 -0000 > It could be the SSDs, the controller, cables, or power supply. > The problem might occur when the data is written, or when it is > read back. If this is occuring on all of the SSDs then look for > some shared component which might be causing the problem. I'll check into these possibilities. Now that I think of it, I should check to see of the Perc card has its own log that I could look at, even though we're not using its RAID features. > Tim, I've run into this a dozen or so times on servers where their > power is "dirty" (i.e. home or small offices with small servers that > use ZFS). If you plug the box into a UPS to condition the line you > may find that the checksum errors go away. It's pretty amazing > to see and happens with both SSD and spinning rust. It's not > always the case, but it's a common enough environmental problem. > Report back if you try this and it solves your problem. I'm pretty sure that's not the case. This server is a new-ish (3 months old?) Dell R630 with redundant power supplies, connected to an industrial APC UPS, connected to an industrial diesel backup generator, housed in a real bone-fide server room with industrial cooling. There's about 80 other physical servers in this room room, and none of the others are exhibiting this behavior. -- Tim Gustafson Technical Lead, Baskin School of Engineering tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@freebsd.org Mon Nov 9 20:55:14 2015 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 2AFBFA29782 for ; Mon, 9 Nov 2015 20:55:14 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 BD2FF132F for ; Mon, 9 Nov 2015 20:55:13 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by wmww144 with SMTP id w144so92709400wmw.1 for ; Mon, 09 Nov 2015 12:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay_co_uk.20150623.gappssmtp.com; s=20150623; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-type; bh=2eOc4z3CuXumacNpojNxycxU2iUxjQwZ5fzi51ocYdU=; b=MZmti1RvKgiri3stBS77vbc8Viunwd7dYNjClMYitd9jEFtUm6NOYvd8OfKGka6eVL 2ZReuDAiA4ozlJG2YIUHdzlbmbsayXftSHlu3kA7MiMSRibrTbgiPiQ2/jFGci+gk8gb iyL+1l2owcBYN5gjyKrIjkkd6GMeVmkhoXSKBsVt6mqODlK+sW2sMI+Vyl0UeVlMA1vi a+aSMr0yWRJ0W2wJpjTv0f6c1QPpj8TpWepzv9rvoFWUMRPBlYBrfllU1wvg0ljRporn 74c4fI8xSsBlTzAvZ6InLz2ECvTWaqvliKa/QTbuRfG84aKWaKgfCRvUsGfSNlSeZJEE RMhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=2eOc4z3CuXumacNpojNxycxU2iUxjQwZ5fzi51ocYdU=; b=duRqu5LXKqrkao1RZxMt1JmOItmYuSe3M6+wsdp8u1LHZ0hdmeWbXOvEhk7qfptYUi 4HyXDOmQI9/m2cQXbnY5/FsMYpKuvA7j8gb+z5OFq5AJNuW3u6xDOqsW8JiMptVVG82Y bHgLrJVM5OoPqE2G1KebK8J1lQNS0tTacVhCq1L9oWcSzbyGd5+hYabjdUqMedeu8DJZ iITglA6CAD1dmYyQ8ktG/JqtLQZa6fkiLA9yFDGKFx+SDEJvQRqbJH15Y5EOgQhKwFmo zKJcgO6pHCEEVbmwpLqVoETlmBdaiS8M0lgOkhr8ppXX1e8QxAR3mh34QHRI3csezstw Mx4g== X-Gm-Message-State: ALoCoQmHof+fSyOzFAFfYZLhknyqWvFhDEGJdPN60L4MV+K5+S9FPsAOCUTZbwvcpHz+sBOg5VDy X-Received: by 10.194.123.162 with SMTP id mb2mr36896179wjb.32.1447102511802; Mon, 09 Nov 2015 12:55:11 -0800 (PST) From: Steven Hartland Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Mon, 9 Nov 2015 20:55:11 +0000 Message-ID: <-7786625913476013857@unknownmsgid> Subject: Re: ZFS RAID 0+1 Throwing Checksum Errors To: Tim Gustafson Cc: "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 09 Nov 2015 20:55:14 -0000 I would check for bad memory or cabling. If you have a hot swap midplane and the disks are linked at 6gbps that could also be the issue. In short it's more likely to be a hardware issue than software > On 9 Nov 2015, at 19:09, Tim Gustafson wrote: > > I have a FreeBSD 10.1 server configured as root-on-zfs with the > following pool configuration: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/zfs0 ONLINE 0 0 0 > gpt/zfs1 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/zfs2 ONLINE 0 0 0 > gpt/zfs3 ONLINE 0 0 0 > > The disks are each 1TB Samsung 850EVO SSDs connected via an mrsas Dell > Perc raid controller configured in "RAID Disabled" mode. > > I run a "zpool scrub" every weekend and every weekend the scrub finds > a handful (usually between 1 and 10) checksum errors per disk. The > scrub fixes the checksum errors, and I clear the counters and > everything seems fine. As far as I know, I do not have any corrupt or > missing data. > > The server is a fairly busy web and database server, handling about 5 > million hits per day. > > I'm wondering if the problem is that the scrub is calculating the > checksum for the data on gpt/zfs0, and while that's happening, some > data is updated by Apache or MySQL, and then checksum for the data on > gpt/zfs1 is calculated, which now doesn't match, and therefore the > scrub is reporting an error. Is that possible? > > If that's not it, could this be a bug? Or should I be worried about > my SSDs? What additional data would be helpful for me to share to > diagnose this? > > -- > > Tim Gustafson > Technical Lead, Baskin School of Engineering > tjg@ucsc.edu > 831-459-5354 > Baskin Engineering, Room 313A > _______________________________________________ > 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 Nov 10 05:38:52 2015 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 76050A2BA46 for ; Tue, 10 Nov 2015 05:38:52 +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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 453C711E7; Tue, 10 Nov 2015 05:38:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-78.lns20.per1.internode.on.net [121.45.229.78]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tAA5cdj2085734 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 9 Nov 2015 21:38:43 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: futimens and utimensat vs birthtime (resurected) To: John Baldwin References: <201508142122.t7ELMPjR002452@chez.mckusick.com> <56401002.8020909@freebsd.org> <10503657.4i3LlcO4Z3@ralph.baldwin.cx> Cc: Kirk McKusick , "freebsd-fs@freebsd.org" , "'Jilles Tjoelker'" From: Julian Elischer Message-ID: <564182D9.8000701@freebsd.org> Date: Tue, 10 Nov 2015 13:38:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <10503657.4i3LlcO4Z3@ralph.baldwin.cx> 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: Tue, 10 Nov 2015 05:38:52 -0000 On 11/10/15 3:09 AM, John Baldwin wrote: > On Monday, November 09, 2015 11:16:18 AM Julian Elischer wrote: >> On 8/15/15 5:22 AM, Kirk McKusick wrote: >>>> From: John Baldwin >>>> To: freebsd-current@freebsd.org >>>> Subject: Re: futimens and utimensat vs birthtime >>>> Date: Fri, 14 Aug 2015 10:39:41 -0700 >>>> Cc: "freebsd-fs@freebsd.org" , >>>> "'Jilles Tjoelker'" >>>> >>>> On Friday, August 14, 2015 10:46:10 PM Julian Elischer wrote: >>>>> I would like to implement this call. but would like input as to it's >>>>> nature. >>>>> The code inside the system would already appear to support handling >>>>> three elements, though it needs some scrutiny, >>>>> so all that is needed is a system call with the ability to set the >>>>> birthtime directly. >>>>> >>>>> Whether it should take the form of the existing calls but expecting >>>>> three items is up for discussion. >>>>> Maybe teh addition of a flags argument to specify which items are >>>>> present and which to set. >>>>> >>>>> ideas? >>>> I believe these should be new calls. Only utimensat() provides a flag >>>> argument, but it is reserved for AT_* flags. I would be fine with >>>> something like futimens3() and utimensat3() (where 3 means "three >>>> timespecs"). Jilles implemented futimens() and utimensat(), so he >>>> might have ideas as well. I would probably stick the birth time in >>>> the third (final) timespec slot to make it easier to update new code >>>> (you can use an #ifdef just around ts[2] without having to #ifdef the >>>> entire block). >>>> >>> I concur with John's suggestion. Add a new system call with three >>> argument set of times specifying birthtime as the last one. I >>> proposed doing this when I added birthtime, but did not as the >>> sentiment at the time was that it would gratuitously make FreeBSD >>> written applications less portable if they used this new non-standard >>> system call. >> time has passed and I would like to get back to this: >> There was some feedback last time. Taking that into account: >> >> One problem with the '3 arg' version is that we have to reinvent it >> again if we get a 4th. >> We could make something like the following: >> >> It has been suggested that a 4th entry might be "last archive time" >> and that >> "time created on this filesystem" and "file created first time (ever)" >> might also >> be separate in some systems. (as examples of why 3 might not be enough) >> >> the syscall name is also not decided. >> one suggested form is: >> $name (int fd, int32 flags/mask, const struct timespec *arrayptr[]); >> >> vs the current: >> utimensat(int fd, const char *path, const struct timespec times[2], >> int flag); >> >> where mask is: >> --- >> 0x01 disable_heuristic >> 0x02 AT_SYMLINK_NOFOLLOW >> 0x04-0x08 unused >> -- times present--- >> 0x10 access time >> 0x20 mod time >> 0x40 birth time >> 0x80 archive time >> 0x100 conception time >> 0x200-on reserverd for future times >> >> any bit not set in 0x010-on is not represented in the array. >> no bits would be a nop (the price for orthogonality) and would >> effectively be the same as a test for writeability. >> "disable heuristic" would disable the forcing of birthtime back to mod >> time or earlier (and any other 'logical fixes') >> setting all 5 'time-present' bits would imply the array has 5 entries. >> >> anyone care to comment > I think the mask is overly complex. utimensat() already has UTIME_OMIT. > I think you should just have a new 'count' argument and use UTIME_OMIT > when you wish to leave a timestamp alone: > > futimens3(int fd, const struct timespec *times, int ntimes); > utimensat5(int fd, const char *path, const struct timespec *ntimes, > int ntimes, int flag); > > ntimes defines how many valid timespecs are in the times[] array. If > you pass in fewer entries than is required, any missing entries at the > end are treated as if they were set to UTIME_OMIT (so not modified). > The new versions would not set birthtime implicitly. For now I would > simply define birthtime as times[2]. One curious idea is if you wanted > to permit setting the change time (right now ctime is implicitly updated > to "now" when you set the time). I think you probably don't want to > allow that. > > The only other thing you might consider is adding constants for the > array indices which might help with portability if other systems adopt > this interface: > > #define TIMENS_ACCESS 0 > #define TIMENS_MODIFICATION 1 > #define TIMENS_BIRTH 2 > #define TIMENS_MAX TIMENS_BIRTH > > This would let you do things like in portable-ish code (if the > interface itself is more widely adopted) where different systems can > define the layout of the array while keeping the API portable. > > struct timespec times[TIMENS_MAX]; > > for (i = 0; i < nitems(times); i++) > times[i].tv_usec = UTIME_OMIT; > #ifdef TIMENS_BIRTH > timens[TIMENS_BIRTH] = foo; > #endif > futimens4(fd, times, nitems(times)); > all makes sense, but one thing I would like to think about from the old one is the ability to check for bad birthtime, unless over-ridden.. i.e. by default it keeps birthtime < modtime. I'm not sure whether this is important to anybody. From owner-freebsd-fs@freebsd.org Tue Nov 10 05:55:31 2015 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 57E2AA2BDC9 for ; Tue, 10 Nov 2015 05:55:31 +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 3B4011923; Tue, 10 Nov 2015 05:55:30 +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 tAA5tTwY071029; Mon, 9 Nov 2015 21:55:29 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201511100555.tAA5tTwY071029@chez.mckusick.com> From: Kirk McKusick To: Julian Elischer Subject: Re: futimens and utimensat vs birthtime (resurected) cc: John Baldwin , "freebsd-fs@freebsd.org" , "'Jilles Tjoelker'" In-reply-to: <564182D9.8000701@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71027.1447134929.1@chez.mckusick.com> Date: Mon, 09 Nov 2015 21:55:29 -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: Tue, 10 Nov 2015 05:55:31 -0000 > To: John Baldwin > Subject: Re: futimens and utimensat vs birthtime (resurected) > Cc: Kirk McKusick , > "freebsd-fs@freebsd.org" , > "'Jilles Tjoelker'" > From: Julian Elischer > Date: Tue, 10 Nov 2015 13:38:33 +0800 > > On 11/10/15 3:09 AM, John Baldwin wrote: > >> I think the mask is overly complex. utimensat() already has UTIME_OMIT. >> I think you should just have a new 'count' argument and use UTIME_OMIT >> when you wish to leave a timestamp alone: >> >> futimens3(int fd, const struct timespec *times, int ntimes); >> utimensat5(int fd, const char *path, const struct timespec *ntimes, >> int ntimes, int flag); >> >> ntimes defines how many valid timespecs are in the times[] array. If >> you pass in fewer entries than is required, any missing entries at the >> end are treated as if they were set to UTIME_OMIT (so not modified). >> The new versions would not set birthtime implicitly. For now I would >> simply define birthtime as times[2]. One curious idea is if you wanted >> to permit setting the change time (right now ctime is implicitly updated >> to "now" when you set the time). I think you probably don't want to >> allow that. >> >> The only other thing you might consider is adding constants for the >> array indices which might help with portability if other systems adopt >> this interface: >> >> #define TIMENS_ACCESS 0 >> #define TIMENS_MODIFICATION 1 >> #define TIMENS_BIRTH 2 >> #define TIMENS_MAX TIMENS_BIRTH >> >> This would let you do things like in portable-ish code (if the >> interface itself is more widely adopted) where different systems can >> define the layout of the array while keeping the API portable. >> >> struct timespec times[TIMENS_MAX]; >> >> for (i = 0; i < nitems(times); i++) >> times[i].tv_usec = UTIME_OMIT; >> #ifdef TIMENS_BIRTH >> timens[TIMENS_BIRTH] = foo; >> #endif >> futimens4(fd, times, nitems(times)); >> > > All makes sense, but one thing I would like to think about from the > old one is the ability to check for bad birthtime, unless over-ridden.. > i.e. by default it keeps birthtime < modtime. I'm not sure whether > this is important to anybody. I added the semantics of setting birthtime < modtime (rather than leaving it at the time the file was most recently created) as that seemed more sensible. But that semantic was just a heuristic. If the system call wants to set it to something that does not meet that heuristic, it absolutely should be able to do so. The heuristic should only be used when absent birthtime being given (e.g., when the old interface is used). Kirk McKusick From owner-freebsd-fs@freebsd.org Tue Nov 10 06:24:40 2015 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 EA746A2A929 for ; Tue, 10 Nov 2015 06:24:40 +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 D7F4114AA for ; Tue, 10 Nov 2015 06:24:40 +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 tAA6OegS047096 for ; Tue, 10 Nov 2015 06:24:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 201677] unionfs or tmpfs kernel panic Date: Tue, 10 Nov 2015 06:24:40 +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-BETA1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 10 Nov 2015 06:24:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201677 --- Comment #3 from Konstantin Belousov --- (In reply to Franco Fichtner from comment #1) tmpfs change is completely wrong, there is no reason for tmpfs vnode lock to be recursive. Unionfs is broken architecturally, it was so for the whole its existence, which is cause of this backtrace and many other issues you could get with the unionfs breaking all assumptions of VFS and filesystems. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 10 06:27:45 2015 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 782E3A2AA35 for ; Tue, 10 Nov 2015 06:27: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 65AC215F0 for ; Tue, 10 Nov 2015 06:27: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 tAA6RjPl051071 for ; Tue, 10 Nov 2015 06:27:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 201677] unionfs or tmpfs kernel panic Date: Tue, 10 Nov 2015 06:27: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-BETA1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: franco@opnsense.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 10 Nov 2015 06:27:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201677 --- Comment #4 from Franco Fichtner --- Cool, what is the proposed workaround or replacement in this case? :) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 10 09:51:06 2015 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 DA5D8A2B712 for ; Tue, 10 Nov 2015 09:51: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 C68E51347 for ; Tue, 10 Nov 2015 09:51: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 tAA9p6DH022709 for ; Tue, 10 Nov 2015 09:51:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 18874] [2TB] 32bit NFS servers export wrong negative values to 64bit clients Date: Tue, 10 Nov 2015 09:51:07 +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: 5.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 10 Nov 2015 09:51:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=18874 NGie Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ngie@FreeBSD.org, | |rmacklem@FreeBSD.org --- Comment #23 from NGie Cooper --- Rick: is this still an issue? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 10 09:52:30 2015 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 05700A2B7E9 for ; Tue, 10 Nov 2015 09:52:30 +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 E62EC17A5 for ; Tue, 10 Nov 2015 09:52:29 +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 tAA9qTHV028359 for ; Tue, 10 Nov 2015 09:52:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 27687] fsck(8) wrapper is not properly passing options to fsck_ Date: Tue, 10 Nov 2015 09:52:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 5.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ngie@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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, 10 Nov 2015 09:52:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=27687 NGie Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |ngie@FreeBSD.org CC| |ngie@FreeBSD.org --- Comment #2 from NGie Cooper --- This annoys me on a regular basis. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 10 09:59:16 2015 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 CB8CBA2B9CF for ; Tue, 10 Nov 2015 09:59:16 +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 B7DEB19E8 for ; Tue, 10 Nov 2015 09:59:16 +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 tAA9xGeR038666 for ; Tue, 10 Nov 2015 09:59:16 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: Tue, 10 Nov 2015 09:59:16 +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: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 10 Nov 2015 09:59:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=9619 NGie Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ngie@FreeBSD.org, | |rmacklem@FreeBSD.org --- Comment #6 from NGie Cooper --- I'm pretty sure this is no longer the case (well, at least with HUP). Rick: can you confirm? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 10 13:38:49 2015 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 7E413A2AABC for ; Tue, 10 Nov 2015 13:38:49 +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 6B2331E1C for ; Tue, 10 Nov 2015 13:38:49 +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 tAADcn32072000 for ; Tue, 10 Nov 2015 13:38:49 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: Tue, 10 Nov 2015 13:38:49 +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-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 10 Nov 2015 13:38:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=9619 --- Comment #7 from Rick Macklem --- In recent versions of FreeBSD, mountd has the "-S" option, which can be used to avoid this from happening. It suspends/resumes the nfsd threads while it is reloading the exports. Some have suggested that it should be enabled by default, but others felt that would be a POLA violation (since all NFS services stop during the suspend), so it has never been made the default and must be enabled via the "-S" option. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Wed Nov 11 02:59:02 2015 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 DADAFA2BBDF for ; Wed, 11 Nov 2015 02:59:02 +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 BE583189F for ; Wed, 11 Nov 2015 02:59:02 +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 tAB2x2tV023694 for ; Wed, 11 Nov 2015 02:59:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 18874] [2TB] 32bit NFS servers export wrong negative values to 64bit clients Date: Wed, 11 Nov 2015 02:59:02 +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: 5.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 11 Nov 2015 02:59:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=18874 --- Comment #24 from Rick Macklem --- The NFSv3 and NFSv4 RFCs specify the field as 64bit unsigned on the wire. To "cheat" and put a negative value in it will break non-BSD clients like Solaris. The new/current FreeBSD server checks for a negative value for f_bavail and puts 0 on the wire if it is negative. The new/current FreeBSD client divides the unsigned 64bit value off the wire by NFS_FABLKSIZE before assigning it to the 64bit signed f_bavail, so it can never be negative (because the unsigned value fits in 63bits after the divide). I think this can be closed, rick -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Wed Nov 11 18:09:10 2015 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 2F612A2CA9B for ; Wed, 11 Nov 2015 18:09:10 +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 1AC81111E for ; Wed, 11 Nov 2015 18:09:10 +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 tABI994Q031665 for ; Wed, 11 Nov 2015 18:09:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 201677] unionfs or tmpfs kernel panic Date: Wed, 11 Nov 2015 18:09:09 +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-BETA1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bdrewery@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 11 Nov 2015 18:09:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201677 --- Comment #5 from Bryan Drewery --- (In reply to Franco Fichtner from comment #4) > Cool, what is the proposed workaround or replacement in this case? :) As Kib pointed out, Unionfs is plain broken. I know of some people who are hacking on it in their spare time, but I don't expect it to be fixed any time soon. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Wed Nov 11 19:13:55 2015 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 78A69A2CDFF for ; Wed, 11 Nov 2015 19:13:55 +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 646441C00 for ; Wed, 11 Nov 2015 19:13:55 +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 tABJDtXN004836 for ; Wed, 11 Nov 2015 19:13:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 201677] unionfs or tmpfs kernel panic Date: Wed, 11 Nov 2015 19:13:55 +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-BETA1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: franco@opnsense.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 11 Nov 2015 19:13:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201677 --- Comment #6 from Franco Fichtner --- So, to wrap this up, I have this one last question: Are there any bad side effects from using this patch as a workaround? Thanks in advance, Franco -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Nov 12 00:59:34 2015 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 69548A2BA8B for ; Thu, 12 Nov 2015 00:59: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 550211FE5 for ; Thu, 12 Nov 2015 00:59: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 tAC0xYmg098682 for ; Thu, 12 Nov 2015 00:59:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204484] ZFS caches on 4K GELI devices accumulate inordinate write errors Date: Thu, 12 Nov 2015 00:59:34 +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-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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, 12 Nov 2015 00:59:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204484 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Nov 12 00:59:45 2015 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 794E9A2BAC7 for ; Thu, 12 Nov 2015 00:59: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 654BB10A3 for ; Thu, 12 Nov 2015 00:59: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 tAC0xjl7098998 for ; Thu, 12 Nov 2015 00:59:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204483] zpool dry-run layouts omit any cache devices specified Date: Thu, 12 Nov 2015 00:59: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: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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, 12 Nov 2015 00:59:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204483 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Nov 12 10:25:59 2015 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 CAB03A2D4A5 for ; Thu, 12 Nov 2015 10:25: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 B848C113F for ; Thu, 12 Nov 2015 10:25: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 tACAPxfd012974 for ; Thu, 12 Nov 2015 10:25:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204484] ZFS caches on 4K GELI devices accumulate inordinate write errors Date: Thu, 12 Nov 2015 10:25: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: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: nowak@tepeserwery.pl X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 12 Nov 2015 10:25:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204484 nowak@tepeserwery.pl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nowak@tepeserwery.pl --- Comment #1 from nowak@tepeserwery.pl --- L2ARC issues physical writes of size possibly not aligned to device block size. zio_vdev_io_start would later align by padding with zeroes. This changed with http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c?r1=268123&r2=268855&pathrev=269093 where IO tagged as physical would not be padded (without fixing L2ARC). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Fri Nov 13 10:13:18 2015 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 90F4AA2DE53; Fri, 13 Nov 2015 10:13:18 +0000 (UTC) (envelope-from bv.sheetalkumar@gmail.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 2A04B120D; Fri, 13 Nov 2015 10:13:18 +0000 (UTC) (envelope-from bv.sheetalkumar@gmail.com) Received: by wmww144 with SMTP id w144so23772904wmw.0; Fri, 13 Nov 2015 02:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NeeKTemU3tWfXhyldxRl1vh/0lSPKN3AYsmLYdGDKQk=; b=Pp6d/Tm7CyimagNhRyCXnpw76hb3oxXnKuJuBdrjeqaRa3xMMZsyP7l0YNQRkCQ6q3 VV3AmWJ8Hsb5N+MXu7QYPIxyLHvnX4X8NiDClZuro2b/h26FP8OJeCzDSJ9TvIs5yoqI /W5bjxaZelV9gPBG3SKjq8ak3E0FXbplNpei31dSb9EXU+TPY16yAl7CEVypAVHKMRoH Km4wwA7YTZ8hiXXRibt/fFaKQjMlCeuxDb1GrCUHDuHSq85JtEiT92sgXyGj62A6YuMQ 5wmcdmbg6tVWAB8DJYhvY3lVrTd5PFDSWY3yPRFwwgDS0koSqqCHuozvaHg+BDXm3xhX /bLw== MIME-Version: 1.0 X-Received: by 10.28.222.138 with SMTP id v132mr1969522wmg.23.1447409595716; Fri, 13 Nov 2015 02:13:15 -0800 (PST) Received: by 10.28.138.77 with HTTP; Fri, 13 Nov 2015 02:13:15 -0800 (PST) Date: Fri, 13 Nov 2015 15:43:15 +0530 Message-ID: Subject: ZTEST failing in FreeBSD 10.1-RC3. From: sheetalkumar BV To: freebsd-fs@freebsd.org, freebsd-testing@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: Fri, 13 Nov 2015 10:13:18 -0000 Hi, I'm Sheetal Kumar from CloudByte Technologies , currently me and my team are exploring FreeBSD 10.1-RC3, when we came across ZFS, we are not able to run ZTEST successfully, we are getting following error when we run ZTEST. *root@bsd10:~ # ztest -t 1 -T 3600 -P 5 -VVVVVVVV * * 5 vdevs, 7 datasets, 1 threads, 3600 seconds... Assertion failed: (tq->tq_freelist != NULL), file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c, line 289. * *child died with signal 6 * So can you guys help us to understand this issue. From owner-freebsd-fs@freebsd.org Fri Nov 13 10:57:47 2015 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 349C7A2E929; Fri, 13 Nov 2015 10:57:47 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 E7A0E1D99; Fri, 13 Nov 2015 10:57:46 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by obdgf3 with SMTP id gf3so71051478obd.3; Fri, 13 Nov 2015 02:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CD+naksxOPBcj7XYXvOCByfpBKjLWT7MbcX6nweR7IM=; b=MEeoKlTwKHJlJqigGEjRJn5huhCheNBmDCwV7lqChhMLdM9D7YSQ9FLTHUw1PTHPgx juiCiBCqWqUScz3A8Qdm4Rcthm6OBDogroSktgGSooRcntdqbBMLAZG1KWUBtPu/Nyz2 xuiC2ghuWFDhwuSJIpnjQryQJkkPioqHv6dQ/7BBuN5MrCF2jAXicEkmmHMJQjFQfjHZ Lim59reNHXy2mb/HKl/GDVJLIZ+7k8Zwxx3i7MjG1aIqS1qEd8XyU+q1OsbS6yhgjtB6 +N5V+88C79i1TmYHgxrTQlaOY+2c8z63FGMF59vybsb9Ih8h3tN8pGWZuBiuruTwjtW8 5How== X-Received: by 10.182.80.9 with SMTP id n9mr11905120obx.14.1447412266252; Fri, 13 Nov 2015 02:57:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.58.2 with HTTP; Fri, 13 Nov 2015 02:57:06 -0800 (PST) In-Reply-To: References: From: Outback Dingo Date: Fri, 13 Nov 2015 21:57:06 +1100 Message-ID: Subject: Re: ZTEST failing in FreeBSD 10.1-RC3. To: sheetalkumar BV Cc: freebsd-fs@freebsd.org, freebsd-testing@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: Fri, 13 Nov 2015 10:57:47 -0000 On Fri, Nov 13, 2015 at 9:13 PM, sheetalkumar BV wrote: > Hi, > I'm Sheetal Kumar from CloudByte Technologies , > currently me and my team are exploring FreeBSD 10.1-RC3, when we came > across ZFS, we are not able to run ZTEST successfully, we are getting > following error when we run ZTEST. > Any specific reason your using 10.1-RC3 ? you might want to look at 10.2-RELEASE as its the latest version of FreeBSD > > *root@bsd10:~ # ztest -t 1 -T 3600 -P 5 -VVVVVVVV > * > > * 5 vdevs, 7 datasets, 1 threads, 3600 seconds... > Assertion failed: (tq->tq_freelist != NULL), file > > /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c, > line 289. * > *child died with signal 6 * > > So can you guys help us to understand this issue. > _______________________________________________ > 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 Fri Nov 13 12:26:27 2015 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 E411DA2E6EB; Fri, 13 Nov 2015 12:26:27 +0000 (UTC) (envelope-from bv.sheetalkumar@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 904351031; Fri, 13 Nov 2015 12:26:27 +0000 (UTC) (envelope-from bv.sheetalkumar@gmail.com) Received: by wmdw130 with SMTP id w130so26781776wmd.0; Fri, 13 Nov 2015 04:26:25 -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=07fT46AWnkvg4NK3J12VSW69P/3HVKsJzhI5ah3M148=; b=g5WMrwfAb9p/+TS24F9+z9eyuwIf10xHmyvm6xwo6mFcOjYWz+SeFa4/upQDlsplWM KzGzra5JX70IdRPH8lQX8DxIbGRIc09OdA8xUVuSpc/PfVf7IxYM8QZYtqWkRMnCYcCO Hao7S5KoBcLJ+nlyicQz+xINJH29PPrWhvs90DdsH5H0GNU8LwnbwrpLfNGkU+yXB4u1 tCPh2ZQEpXsjajrhnLQvxiAZHClTQDGQtS70mwG95baIjCOxpXEfKvo4+4Kc0VgONYzg 4JCEJ37fe9cIZE+ufV+l4Ja/cNpKESzoxfn5+Glz4MI5vEnxhXc4yVroe7V8qbvFWvW8 2pFA== MIME-Version: 1.0 X-Received: by 10.28.48.10 with SMTP id w10mr3322378wmw.39.1447417585873; Fri, 13 Nov 2015 04:26:25 -0800 (PST) Received: by 10.28.138.77 with HTTP; Fri, 13 Nov 2015 04:26:25 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Nov 2015 17:56:25 +0530 Message-ID: Subject: Re: ZTEST failing in FreeBSD 10.1-RC3. From: sheetalkumar BV To: Outback Dingo Cc: freebsd-fs@freebsd.org, freebsd-testing@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: Fri, 13 Nov 2015 12:26:28 -0000 When we started using FreeBSD-10 version, that time 10.1-RC3 was available. Apart from this there is no specific reason to choose 10.1 version. Are you suggesting to use 10.2-RELEASE? Can I expect ZTEST command working in 10.2-RELEASE? On Fri, Nov 13, 2015 at 4:27 PM, Outback Dingo wrote: > > > On Fri, Nov 13, 2015 at 9:13 PM, sheetalkumar BV < > bv.sheetalkumar@gmail.com> wrote: > >> Hi, >> I'm Sheetal Kumar from CloudByte Technologies > >, >> currently me and my team are exploring FreeBSD 10.1-RC3, when we came >> across ZFS, we are not able to run ZTEST successfully, we are getting >> following error when we run ZTEST. >> > > Any specific reason your using 10.1-RC3 ? you might want to look at > 10.2-RELEASE as its the latest version of FreeBSD > > > >> >> *root@bsd10:~ # ztest -t 1 -T 3600 -P 5 -VVVVVVVV >> * >> >> * 5 vdevs, 7 datasets, 1 threads, 3600 seconds... >> Assertion failed: (tq->tq_freelist != NULL), file >> >> /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c, >> line 289. * >> *child died with signal 6 * >> >> So can you guys help us to understand this issue. >> _______________________________________________ >> 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 Fri Nov 13 18:17:31 2015 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 1DC46A2EEBD for ; Fri, 13 Nov 2015 18:17:31 +0000 (UTC) (envelope-from fusionfoto@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 CCDAF1967 for ; Fri, 13 Nov 2015 18:17:30 +0000 (UTC) (envelope-from fusionfoto@gmail.com) Received: by qkfo3 with SMTP id o3so55386160qkf.1 for ; Fri, 13 Nov 2015 10:17:30 -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 :content-type; bh=yR31niZpOAnojjwtusJVSJyGyDcg9+/QubyycyxxDtE=; b=RAybwezBy4OPURIpb5D8FeV2wl0zuYqHI6lkYQWfXS5ssjgQni3bO+o4Nh5ScYLA/H GgNzxJt6c2iXaZzO13/u8NkCtn92riAtN7OLwUIlcwY81qxsjMGrwXd4nZdJNrLCUd41 eRX34DrV+myncEC4FQo8KdU8RSeeS3d5aNS7mLsGEGUvc51A4mmwy7K7TZLGExiZ1P/m rBpoMHqfJkI43GGKPGB6dOF3oij5vRq2/ONeMgeu6WJZHokRRxrCvMkOv1mVG9qZ13aq 42Txv0BR8FWPFuRc1QVAsKDCvxpA0PNVH/M/K4PBCRDC5cmEm2CBwaVPMZAw/IBCuWaR wwIA== MIME-Version: 1.0 X-Received: by 10.140.42.164 with SMTP id c33mr13556411qga.66.1447438649825; Fri, 13 Nov 2015 10:17:29 -0800 (PST) Received: by 10.55.41.163 with HTTP; Fri, 13 Nov 2015 10:17:29 -0800 (PST) In-Reply-To: References: <5629E4F5.3030500@multiplay.co.uk> Date: Fri, 13 Nov 2015 13:17:29 -0500 Message-ID: Subject: Fwd: Adjusting zvol_immediate_write_sz From: FF To: 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: Fri, 13 Nov 2015 18:17:31 -0000 This is what I wrote up. It compiles into 9.2 and executes fine. I looked at the section on 9.3 and it doesn't appear that any changes would be required. Thanks in advance, to whomever looks at it. # pwd /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs # more patch --- zvol.c.orig 2015-10-23 18:50:25.000000000 -0400 +++ zvol.c 2015-10-23 18:53:04.000000000 -0400 @@ -1103,6 +1103,12 @@ * Otherwise we will later flush the data out via dmu_sync(). */ ssize_t zvol_immediate_write_sz = 32768; +SYSCTL_DECL(_vfs_zfs); +TUNABLE_QUAD("vfs.zfs.zil_immediate_write_sz", &zvol_immediate_write_sz); +SYSCTL_QUAD(_vfs_zfs, OID_AUTO, zil_immediate_write_sz, CTLFLAG_RW, + &zvol_immediate_write_sz, 0, "Controls ZIL behavior by adjusting size of immediate write"); + + static void zvol_log_write(zvol_state_t *zv, dmu_tx_t *tx, offset_t off, ssize_t resid, ------- If you need me to conform it as a patch against / or /usr/src, just let me know. Thanks! From owner-freebsd-fs@freebsd.org Fri Nov 13 23:44:50 2015 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 1A448A2EFDC for ; Fri, 13 Nov 2015 23:44:50 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 AA8C0124F for ; Fri, 13 Nov 2015 23:44:48 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-f79216d00000156e-e2-564674bb0d44 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 05.38.05486.BB476465; Fri, 13 Nov 2015 18:39:39 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tADNdcLR021160; Fri, 13 Nov 2015 18:39:39 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tADNdZ0s006570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 18:39:38 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tADNdZBq003420; Fri, 13 Nov 2015 18:39:35 -0500 (EST) Date: Fri, 13 Nov 2015 18:39:35 -0500 (EST) From: Benjamin Kaduk To: FF cc: freebsd-fs@freebsd.org Subject: Re: Fwd: Adjusting zvol_immediate_write_sz In-Reply-To: Message-ID: References: <5629E4F5.3030500@multiplay.co.uk> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrbu7xC3MYPtxSYtjj3+yWex7vZTN gcljxqf5LB47Z91lD2CK4rJJSc3JLEst0rdL4Mr4s4m7YAZrxcE9r9gbGDtYuhg5OSQETCRu /prHCmGLSVy4t56ti5GLQ0hgMZPEhhmrmSGcjYwSz7edY4FwDjFJ3F89H8ppYJSYOXs7O0g/ i4C2xN5nB8BmsQmoSMx8s5ENxBYRkJU4vOQPUxcjBwezgJTEnbUVIGFhAWOJGx8fM4HYnAKB EtMW9YCV8wo4SmyZ1c8IMf8Ik8SE33/BbhUV0JFYvX8KC0SRoMTJmU/AbGYBLYnl07exTGAU nIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTSTYygUGV3UdnB2HxI 6RCjAAejEg+vho5bmBBrYllxZe4hRkkOJiVR3sY8oBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3ggToBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTv7mKgRsGi1PTU irTMnBKENBMHJ8hwHqDhN0BqeIsLEnOLM9Mh8qcYdTkW/Li9lkmIJS8/L1VKnPcQSJEASFFG aR7cHHCK2c2k+opRHOgtYd4AkCoeYHqCm/QKaAkT0BKBSa4gS0oSEVJSDYwrD69l1z3l4Rch 6nysOfvPL4aJFi4T+z+7zthi8+AOz92nVVnLPu46yHqo0ueu+JpHkmfiKrfsvxvrrrQ/oTZx wlR3wyd/cj6flLU98Xl+6OZlJ/+zz/53M2KNt+Dxnt8ZurwZLba/9l93VGw4qaViZydV2pO+ WdGk1OFhmfiszOhghaXx26SUWIozEg21mIuKEwGP0A+UDAMAAA== 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, 13 Nov 2015 23:44:50 -0000 On Fri, 13 Nov 2015, FF wrote: > This is what I wrote up. It compiles into 9.2 and executes fine. I looked > at the section on 9.3 and it doesn't appear that any changes would be > required. Thanks in advance, to whomever looks at it. Changes to FreeBSD first go into the development trunk and are only merged back to the stable release branches after they have had some time to settle. 9.3 is already released and releng/9.3 will only be modified for security advisories and errata notices, for which this does not seem to qualify. So, it would be better to check the sources in HEAD than 9.3. -Ben Kaduk P.S. 9.2 hit EoL at the end of 2014. From owner-freebsd-fs@freebsd.org Sat Nov 14 05:04:28 2015 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 C9EBFA2D961; Sat, 14 Nov 2015 05:04:28 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 17FBF1558; Sat, 14 Nov 2015 05:04:26 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp14-2-8-239.lns21.adl2.internode.on.net (HELO leader.local) ([14.2.8.239]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Nov 2015 15:29:16 +1030 Subject: Re: ZTEST failing in FreeBSD 10.1-RC3. To: sheetalkumar BV , Outback Dingo References: Cc: freebsd-fs@freebsd.org, freebsd-testing@freebsd.org From: Shane Ambler Message-ID: <5646BF54.1030900@ShaneWare.Biz> Date: Sat, 14 Nov 2015 15:27:56 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; 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: Sat, 14 Nov 2015 05:04:28 -0000 On 13/11/2015 22:56, sheetalkumar BV wrote: > When we started using FreeBSD-10 version, that time 10.1-RC3 was available. > Apart from this there is no specific reason to choose 10.1 version. > > Are you suggesting to use 10.2-RELEASE? Can I expect ZTEST command working > in 10.2-RELEASE? >>> >>> *root@bsd10:~ # ztest -t 1 -T 3600 -P 5 -VVVVVVVV >>> * I am running 10-STABLE (built about 3 weeks ago) and ztest runs. FreeBSD leader.local 10.2-STABLE FreeBSD 10.2-STABLE #18 r288131:Sat Sep 26 17:45:26 ACST 2015 shane@leader.local:/usr/obj/usr/src/sys/GENERIC amd64 % ztest -t 1 -T 3600 -P 5 -VVVVVVVV 5 vdevs, 7 datasets, 1 threads, 3600 seconds... Executing zdb -bccsv -d -U /tmp/zpool.cache ztest loading space map for vdev 0 of 1, metaslab 12 of 30 ... Dataset mos [META], ID 0, cr_txg 4, 44.9K, 37 objects ... ... -- FreeBSD - the place to B...Storing Data Shane Ambler