From owner-freebsd-fs@freebsd.org Tue Jun 2 16:38:49 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBD542F3CD2 for ; Tue, 2 Jun 2020 16:38:49 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) Received: from mail.cock.li (mail.cock.li [37.120.193.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49byRD6NKmz4FGb for ; Tue, 2 Jun 2020 16:38:48 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) From: goatshit54108@national.shitposting.agency DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=national.shitposting.agency; s=mail; t=1591115522; bh=1qCi5qBp75Pyt5QThHrsj1Z0tjgOkFbIkr7UpRqZVG8=; h=From:Subject:To:Date:From; b=bjDQWGi/feLZJeXLO9OiMFzo4IXaEOi3VYoBgu0E3F19F1OIUJ/uz0usKxgBVpnHU R5Do/M9QWSAUAo+IGy4Mfw5gQ13jD1afpZpz82UjbFZMpH7VKZHoBst9HJak4iv8md zMcK8IckH0FU+frQUNREHOux+rCy7VHO6LT1NpNv9SdnzgQC2Kn+rr5g7m2OuakvUW NRdSL61QeFAUPsh0mJ7UiXM1eaHoVOuemGH41bviop0T8QPyBQxWGg8fDOW4xSfQ4v MuGxhFdAMvBd2dE4OQRTL+aQn4vy+lL7OGEexGl2KGI99u1i9ovtW+77YiRjjai181 VD3Ph3BB1KBFw== Subject: fsck this shit To: freebsd-fs@freebsd.org Message-ID: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> Date: Tue, 2 Jun 2020 16:31:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49byRD6NKmz4FGb X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=national.shitposting.agency header.s=mail header.b=bjDQWGi/; dmarc=none; spf=fail (mx1.freebsd.org: domain of goatshit54108@national.shitposting.agency does not designate 37.120.193.124 as permitted sender) smtp.mailfrom=goatshit54108@national.shitposting.agency X-Spamd-Result: default: False [5.39 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; R_DKIM_ALLOW(-0.20)[national.shitposting.agency:s=mail]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.63)[0.628]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shitposting.agency]; NEURAL_SPAM_MEDIUM(0.08)[0.082]; RCPT_COUNT_ONE(0.00)[1]; VIOLATED_DIRECT_SPF(3.50)[]; DKIM_TRACE(0.00)[national.shitposting.agency:+]; NEURAL_SPAM_LONG(0.48)[0.476]; FROM_NO_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:9009, ipnet:37.120.193.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; GREYLIST(0.00)[pass,body] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 16:38:49 -0000 Once upon a time, the power ran out, and then... ** SU+J Recovering /dev/<...> ** Reading 33554432 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. fsck: /dev/<...>: Segmentation fault GAAAY. OK, let's check the core dump... oh, wait... tough luck. Fortunately, subsequent runs of fsck ended up likewise, so I was able to get a core dump by re-executing fsck while being inside a TMPFS-backed directory. (On the other hand, unfortunately, fsck was never able to replay the journal.) Furthermore, I saved the .sujournal file, but saving the contents of the whole filesystem was beyond my resources. (It would have been adequate to use a tool that collected (only) the blocks that fsck read before segfaulting (thus constructing a small test case), but no such tool was at hand.) Before running "fsck -y" (because I had no other options) I looked at "fsck -n" to see whether a particular, large file would get idiotically removed as part of "fixing" the filesystem. This routine is prompted by (1) personal experiences of files getting lost or truncated to 0 length, and (2) past reports of disasterous behaviors involving soft updates, such as untouched (read-only) files getting lost; "lost" means not even relinked to /lost+found or anything. And wouldn't ya know it, fsck did ask whether to remove something that had an unambiguously large size (to be exact, IIRC: "DUP ... REMOVE?", whatever that means). That's it, either (a) remove the file, or (b) stay dirty; take it or leave it. It's not like there was some 3rd option to relink the file to /lost+found. After "fsck -y", the file disappeared without a trace. GAAAAAAAAAY. The fsck_ffs (or fsck_ufs) file was the one distributed with the 12.1-RELEASE, the one with the SHA3-256 checksum of 447592ae05dc7829823901700bb90940968cae006719964d39b1212bb312d164. Let's see the backtrace: * thread #1, name = 'fsck_ufs', stop reason = signal SIGSEGV * frame #0: 0x0000000000219d93 fsck_ffs`blk_free(bno=10692928, mask=0, frags=134643471) at suj.c:653:34 frame #1: 0x000000000021a481 fsck_ffs`ino_trunc(ino=5296913, size=134610944) at suj.c:1547:3 frame #2: 0x0000000000216fee fsck_ffs`suj_check [inlined] cg_adj_blk(sc=0x0000000801574540) at suj.c:1788:5 frame #3: 0x0000000000216fc3 fsck_ffs`suj_check [inlined] cg_apply at suj.c:1900 frame #4: 0x0000000000216fa5 fsck_ffs`suj_check(filesys="/dev/<...>") at suj.c:2737 frame #5: 0x000000000020ef54 fsck_ffs`main [inlined] checkfilesys(filesys="/dev/<...>") at main.c:427:9 frame #6: 0x000000000020ef07 fsck_ffs`main(argc=1, argv=0x00007fffffffec48) at main.c:205 frame #7: 0x000000000020810f fsck_ffs`_start(ap=, cleanup=) at crt1.c:76:7 Some analysis: 1. It's obvious that frags=134643471 is absurd. 2. The value of `frags` in frame #0 comes from the value of `frags` in frame #1. Regarding frame #1, which is a state of ino_trunc(): it is very suspicious that `frags` is assigned only in the first loop -- conditionally, even --, but is repeatedly used in the second loop. Is the 134643471 memory garbage? This smells GAAY. 3. In frame #0, we have i == 28262448, which means that relevant loop managed to garble >28 Mb of memory with 1-bits, as can be seen by the following: in frame #1, we have ip->dp2 == { di_mode = 65535 di_nlink = -1 di_uid = 4294967295 di_gid = 4294967295 di_blksize = 4294967295 di_size = 18446744073709551615 di_blocks = 18446744073709551615 di_atime = -1 di_mtime = -1 di_ctime = -1 di_birthtime = -1 di_mtimensec = -1 di_atimensec = -1 di_ctimensec = -1 di_birthnsec = -1 di_gen = 4294967295 di_kernflags = 4294967295 di_flags = 4294967295 di_extsize = 4294967295 di_extb = ([0] = -1, [1] = -1) di_db = ([0] = -1, [1] = -1, [2] = -1, [3] = -1, [4] = -1, [5] = -1, [6] = -1, [7] = -1, [8] = -1, [9] = -1, [10] = -1, [11] = -1) di_ib = ([0] = -1, [1] = -1, [2] = -1) di_modrev = 18446744073709551615 di_freelink = 4294967295 di_spare = ([0] = 4294967295, [1] = 4294967295, [2] = 4294967295) }. 4. By the way, *fs == { fs_firstfield = 0 fs_unused_1 = 0 fs_sblkno = 24 fs_cblkno = 32 fs_iblkno = 40 fs_dblkno = 5056 fs_old_cgoffset = 0 fs_old_cgmask = 0 fs_old_time = 0 fs_old_size = 0 fs_old_dsize = 0 fs_ncg = 164 fs_bsize = 32768 fs_fsize = 4096 fs_frag = 8 fs_minfree = 0 fs_old_rotdelay = 0 fs_old_rps = 0 fs_bmask = -32768 fs_fmask = -4096 fs_bshift = 15 fs_fshift = 12 fs_maxcontig = 4 fs_maxbpg = 4096 fs_fragshift = 3 fs_fsbtodb = 3 fs_sbsize = 4096 fs_spare1 = ([0] = 0, [1] = 0) fs_nindir = 4096 fs_inopb = 128 fs_old_nspf = 0 fs_optim = 1 fs_old_npsect = 0 fs_old_interleave = 0 fs_old_trackskew = 0 fs_id = ([0] = 1568391747, [1] = 841092898) fs_old_csaddr = 0 fs_cssize = 4096 fs_cgsize = 32768 fs_spare2 = 0 fs_old_nsect = 0 fs_old_spc = 0 fs_old_ncyl = 0 fs_old_cpg = 0 fs_ipg = 80256 fs_fpg = 160280 fs_old_cstotal = (cs_ndir = 0, cs_nbfree = 0, cs_nifree = 0, cs_nffree = 0) fs_fmod = '\0' fs_clean = '\0' fs_ronly = '\0' fs_old_flags = '\x80' fs_fsmnt = { [0] = '/' [1] = '\0' ... } fs_volname = { [0] = '\0' } fs_swuid = 0 fs_pad = 0 fs_cgrotor = 91 fs_ocsp = ([0] = 0x0000000000000000, [1] = 0x0000000000000000, [2] = 0x0000000000000000, [3] = 0x0000000000000000, [4] = 0x0000000000000000, [5] = 0x0000000000000000, [6] = 0x0000000000000000, [7] = 0x0000000000000000, [8] = 0x0000000000000000, [9] = 0x0000000000000000, [10] = 0x0000000000000000, [11] = 0x0000000000000000) fs_contigdirs = 0x0000000800692a90 fs_csp = 0x000000080069e000 fs_maxcluster = 0x0000000800692800 fs_active = 0x0000000000000000 fs_old_cpc = 0 fs_maxbsize = 32768 fs_unrefs = 0 fs_providersize = 26250240 fs_metaspace = 6408 fs_sparecon64 = ([0] = 0, [1] = 0, [2] = 0, [3] = 0, [4] = 0, [5] = 0, [6] = 0, [7] = 0, [8] = 0, [9] = 0, [10] = 0, [11] = 0, [12] = 0) fs_sblockactualloc = 65536 fs_sblockloc = 65536 fs_cstotal = { cs_ndir = 54923 cs_nbfree = 188121 cs_nifree = 12699260 cs_nffree = 59369 cs_numclusters = 0 cs_spare = ([0] = 0, [1] = 0, [2] = 0) } fs_time = 1588190343 fs_size = 26250240 fs_dsize = 25424967 fs_csaddr = 5056 fs_pendingblocks = 0 fs_pendinginodes = 0 fs_snapinum = { [0] = 0 ... } fs_avgfilesize = 16384 fs_avgfpdir = 64 fs_save_cgsize = 0 fs_mtime = 1588178967 fs_sujfree = 0 fs_sparecon32 = { [0] = 0 ... } fs_metackhash = 2 fs_flags = 522 fs_contigsumsize = 4 fs_maxsymlinklen = 120 fs_old_inodefmt = 0 fs_maxfilesize = 2252349704110079 fs_qbmask = 32767 fs_qfmask = 4095 fs_state = 0 fs_old_postblformat = 0 fs_old_nrpos = 0 fs_spare5 = ([0] = 0, [1] = 0) fs_magic = 424935705 }. From owner-freebsd-fs@freebsd.org Tue Jun 2 21:46:47 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B56182FBC0E for ; Tue, 2 Jun 2020 21:46:47 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from p-impout001.msg.pkvw.co.charter.net (p-impout008aa.msg.pkvw.co.charter.net [47.43.26.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49c5GZ0Qmqz3d9t for ; Tue, 2 Jun 2020 21:46:45 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from localhost ([96.28.177.163]) by cmsmtp with ESMTP id gEk2jb7b9rzR3gEk2jlvp3; Tue, 02 Jun 2020 21:46:39 +0000 X-Authority-Analysis: v=2.3 cv=Ne6YKFL4 c=1 sm=1 tr=0 a=xqrt2BZAGHte7XHhrxJgbA==:117 a=xqrt2BZAGHte7XHhrxJgbA==:17 a=HpEJnUlJZJkA:10 a=DBwwDor5xuMA:10 a=qz5MpHPoCsHZqr7YxSUA:9 a=FIdtiwb641T6Oyvz:21 a=qQn6kh7PZddSMNYG:21 a=pHzHmUro8NiASowvMSCR:22 a=n87TN5wuljxrRezIQYnT:22 From: "Thomas Mueller" To: freebsd-fs@freebsd.org Subject: Re: fsck this shit References: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> X-CMAE-Envelope: MS4wfBBGzuUdMJRB77oD2rsmspRCa2MiPVVGftU7BlqmgBNIYNwd8Yc16L/V6W2jOiLM7w4rT8lkYi0AzjSgGMNniwpet0l/85hHeay+nkb+nTaecyq3v5NQ f53BSY2BEt7kd0gNl2tQET+N3mrtFyHb50ZqmeJtXHoNTnxJMwzWGzUgAitZ6FfpENDEVoyMrz+6wkIN0P7BssHhQlrROs21onr0/z11q5WmRHLdQVis3okJ X-Rspamd-Queue-Id: 49c5GZ0Qmqz3d9t X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mueller6722@twc.com designates 47.43.26.139 as permitted sender) smtp.mailfrom=mueller6722@twc.com X-Spamd-Result: default: False [2.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.54)[-0.542]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[twc.com]; MISSING_DATE(1.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[twc.com]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; NEURAL_HAM_LONG(-0.11)[-0.110]; MISSING_MID(2.50)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.04)[-0.043]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[twc.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.28.177.163:received] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 02 Jun 2020 21:46:47 -0000 X-List-Received-Date: Tue, 02 Jun 2020 21:46:47 -0000 from goatshit54108@national.shitposting.agency: > Once upon a time, the power ran out, and then... > ** SU+J Recovering /dev/<...> > ** Reading 33554432 byte journal from inode 4. > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > fsck: /dev/<...>: Segmentation fault GAAAY. > OK, let's check the core dump... oh, wait... tough luck. Fortunately, subsequent runs of fsck ended up likewise, so I was able to get a core dump by re-executing fsck while being inside a TMPFS-backed directory. (On the other hand, unfortunately, fsck was never able to replay the journal.) Furthermore, I saved the .sujournal file, but saving the contents of the whole filesystem was beyond my resources. (It would have been adequate to use a tool that collected (only) the blocks that fsck read before segfaulting (thus constructing a small test case), but no such tool was at hand.) > Before running "fsck -y" (because I had no other options) I looked at "fsck -n" to see whether a particular, large file would get idiotically removed as part of "fixing" the filesystem. This routine is prompted by (1) personal experiences of files getting lost or truncated to 0 length, and (2) past reports of disasterous behaviors involving soft updates, such as untouched (read-only) files getting lost; "lost" means not even relinked to /lost+found or anything. And wouldn't ya know it, fsck did ask whether to remove something that had an unambiguously large size (to be exact, IIRC: "DUP ... REMOVE?", whatever that means). That's it, either (a) remove the file, or (b) stay dirty; take it or leave it. It's not like there was some 3rd option to relink the file to /lost+found. After "fsck -y", the file disappeared without a trace. GAAAAAAAAAY. > The fsck_ffs (or fsck_ufs) file was the one distributed with the 12.1-RELEASE, the one with the SHA3-256 checksum of 447592ae05dc7829823901700bb90940968cae006719964d39b1212bb312d164. Let's see the backtrace: > * thread #1, name = 'fsck_ufs', stop reason = signal SIGSEGV > * frame #0: 0x0000000000219d93 fsck_ffs`blk_free(bno=10692928, mask=0, frags=134643471) at suj.c:653:34 > frame #1: 0x000000000021a481 fsck_ffs`ino_trunc(ino=5296913, size=134610944) at suj.c:1547:3 > frame #2: 0x0000000000216fee fsck_ffs`suj_check [inlined] cg_adj_blk(sc=0x0000000801574540) at suj.c:1788:5 > frame #3: 0x0000000000216fc3 fsck_ffs`suj_check [inlined] cg_apply at suj.c:1900 > frame #4: 0x0000000000216fa5 fsck_ffs`suj_check(filesys="/dev/<...>") at suj.c:2737 > frame #5: 0x000000000020ef54 fsck_ffs`main [inlined] checkfilesys(filesys="/dev/<...>") at main.c:427:9 > frame #6: 0x000000000020ef07 fsck_ffs`main(argc=1, argv=0x00007fffffffec48) at main.c:205 > frame #7: 0x000000000020810f fsck_ffs`_start(ap=, cleanup=) at crt1.c:76:7 > Some analysis: (snip) I have had times when fsck_ffs from FreeBSD didn't succeed, but fsck_ffs from NetBSD did succeed. That was on a FreeBSD installation, but I also had/have NetBSD installed. I use GPT with no traditional BSD disklabels, so FreeBSD and NetBSD can read and write each other's partitions. I ran "host national.shitposting.agency", and got national.shitposting.agency has address 52.11.159.5 national.shitposting.agency mail is handled by 20 mx2.cock.li. national.shitposting.agency mail is handled by 10 mx1.cock.li. so the domain really exists. Tom From owner-freebsd-fs@freebsd.org Wed Jun 3 20:22:43 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6456E2F23D6 for ; Wed, 3 Jun 2020 20:22:43 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49cgM62Kb4z4c6Y for ; Wed, 3 Jun 2020 20:22:42 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest-mbp.local (unknown [IPv6:2001:67c:708:101:1c00:9c12:f1ad:361d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id BECB0307F8 for ; Wed, 3 Jun 2020 20:22:31 +0000 (UTC) Subject: Re: fsck this shit To: freebsd-fs@freebsd.org References: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> From: Jan Bramkamp Message-ID: Date: Wed, 3 Jun 2020 22:22:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 49cgM62Kb4z4c6Y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-2.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.68)[-0.679]; DMARC_NA(0.00)[rlwinm.de]; NEURAL_HAM_SHORT(-0.43)[-0.427]; NEURAL_HAM_MEDIUM(-0.67)[-0.674]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 20:22:43 -0000 On 03.06.20 22:18, Thomas Mueller wrote: > from goatshit54108@national.shitposting.agency: > >> Once upon a time, the power ran out, and then... >> ** SU+J Recovering /dev/<...> >> ** Reading 33554432 byte journal from inode 4. >> ** Building recovery table. >> ** Resolving unreferenced inode list. >> ** Processing journal entries. >> fsck: /dev/<...>: Segmentation fault > GAAAY. > >> OK, let's check the core dump... oh, wait... tough luck. Fortunately, subsequent runs of fsck ended up likewise, so I was able to get a core dump by re-executing fsck while being inside a TMPFS-backed directory. (On the other hand, unfortunately, fsck was never able to replay the journal.) Furthermore, I saved the .sujournal file, but saving the contents of the whole filesystem was beyond my resources. (It would have been adequate to use a tool that collected (only) the blocks that fsck read before segfaulting (thus constructing a small test case), but no such tool was at hand.) >> Before running "fsck -y" (because I had no other options) I looked at "fsck -n" to see whether a particular, large file would get idiotically removed as part of "fixing" the filesystem. This routine is prompted by (1) personal experiences of files getting lost or truncated to 0 length, and (2) past reports of disasterous behaviors involving soft updates, such as untouched (read-only) files getting lost; "lost" means not even relinked to /lost+found or anything. And wouldn't ya know it, fsck did ask whether to remove something that had an unambiguously large size (to be exact, IIRC: "DUP ... REMOVE?", whatever that means). That's it, either (a) remove the file, or (b) stay dirty; take it or leave it. It's not like there was some 3rd option to relink the file to /lost+found. After "fsck -y", the file disappeared without a trace. GAAAAAAAAAY. > >> The fsck_ffs (or fsck_ufs) file was the one distributed with the 12.1-RELEASE, the one with the SHA3-256 checksum of 447592ae05dc7829823901700bb90940968cae006719964d39b1212bb312d164. Let's see the backtrace: >> * thread #1, name = 'fsck_ufs', stop reason = signal SIGSEGV >> * frame #0: 0x0000000000219d93 fsck_ffs`blk_free(bno=10692928, mask=0, frags=134643471) at suj.c:653:34 >> frame #1: 0x000000000021a481 fsck_ffs`ino_trunc(ino=5296913, size=134610944) at suj.c:1547:3 >> frame #2: 0x0000000000216fee fsck_ffs`suj_check [inlined] cg_adj_blk(sc=0x0000000801574540) at suj.c:1788:5 >> frame #3: 0x0000000000216fc3 fsck_ffs`suj_check [inlined] cg_apply at suj.c:1900 >> frame #4: 0x0000000000216fa5 fsck_ffs`suj_check(filesys="/dev/<...>") at suj.c:2737 >> frame #5: 0x000000000020ef54 fsck_ffs`main [inlined] checkfilesys(filesys="/dev/<...>") at main.c:427:9 >> frame #6: 0x000000000020ef07 fsck_ffs`main(argc=1, argv=0x00007fffffffec48) at main.c:205 >> frame #7: 0x000000000020810f fsck_ffs`_start(ap=, cleanup=) at crt1.c:76:7 >> Some analysis: > (snip) > > I have had times when fsck_ffs from FreeBSD didn't succeed, but fsck_ffs from NetBSD did succeed. That was on a FreeBSD installation, but I also had/have NetBSD installed. > > I use GPT with no traditional BSD disklabels, so FreeBSD and NetBSD can read and write each other's partitions. > > I ran "host national.shitposting.agency", and got > > national.shitposting.agency has address 52.11.159.5 > national.shitposting.agency mail is handled by 20 mx2.cock.li. > national.shitposting.agency mail is handled by 10 mx1.cock.li. > > so the domain really exists. Yes as you can see in the MX records its run by a bunch of well known racists and faschists who also brought us nice domains like hitler.rocks, nigge.rs. nuke.africa and rape.lol. From owner-freebsd-fs@freebsd.org Wed Jun 3 22:54:27 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9AA42F56E5 for ; Wed, 3 Jun 2020 22:54:27 +0000 (UTC) (envelope-from jdelisle@gmail.com) Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ckkB37ZVz3xwB for ; Wed, 3 Jun 2020 22:54:26 +0000 (UTC) (envelope-from jdelisle@gmail.com) Received: by mail-il1-x141.google.com with SMTP id p5so4222762ile.6 for ; Wed, 03 Jun 2020 15:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l7brOPywC/A5nMRGp2CSe+KI9hEM/C4rRslLesAii+k=; b=H8GcymKJWs4q1AwNx01hNMCJ6Ko5WFWNVKITpRgprhBnYi6ybWYLohOpA6VpCMO2Fw xHyRQiDOuRjYZHiN8a81zlxRfbLbCL2OEcQFzzGbT1L/KSg0PZFImDy9CbiB7Fq7InSX 0OPmzQ5FguAKcxPoCEO1POdXNJ6kC+PzPvAxGHbTAlMU51xU3162gAnsHEFsT3N4mITC RgesFqr6n2D9O+NhdnVVvKdpCfettqfXcVtpucv9lkCZcciEOrTBhjzl0ABfgcJAUpB8 kEztHMYGqIm3w9Kw1y43Pcx7Tsst77s7xPYWg7pk3GSNdLqf3CO6/Qbvjx4bT2HPf7rT slrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l7brOPywC/A5nMRGp2CSe+KI9hEM/C4rRslLesAii+k=; b=DhL3SgJWVNqzwWhODOZD7ESIYlrwRFj7tTwZILJsAhTAJNxvYQkWGHkUvXHNXNdxsV dpPlC25FU1hCem8DGzS2NnK6Qdyenb0qtkyVl7NP8zSQ27B++xPxm/t0vBXQAn6xFPMt 1KCYymEaeZhjBQr1as34qg73magmgTDPdBynxpJSPsZRS7ueaXBBeBL6Y/MFw1l6+/nr EPg9p+s/TAx4QzhJwoWtjskNi7EnUey6/05BNjk3qFJPgTOwUp3MQ77wlEZriNSfVOTa l2EBKDUrLlp2z7YnpY5PTg1msMMZul6wHauGNtrkp4qSy25xKbmk4LkDhsNXTXj7LpG3 BOvw== X-Gm-Message-State: AOAM5315rRf/gKm+AKkW8rJIeBbcLuQwSofuC/gMKaRVo5J5cai5pr/1 l2bsQRY2elFFnLvL8Bakj8mhInapOT1BJZky+vmdDppA X-Google-Smtp-Source: ABdhPJxTHBL6qeqsTNEntnWkzX4WK4QRgr3ZgzAcdTakL5T5kaBCBZh2HVggNBm67S6Atgy10IRAc0Pa0rA6btZDU/M= X-Received: by 2002:a92:bacb:: with SMTP id t72mr1734511ill.26.1591224865317; Wed, 03 Jun 2020 15:54:25 -0700 (PDT) MIME-Version: 1.0 References: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> In-Reply-To: From: jdelisle Date: Wed, 3 Jun 2020 17:54:13 -0500 Message-ID: Subject: Re: fsck this shit To: Jan Bramkamp Cc: freebsd-fs X-Rspamd-Queue-Id: 49ckkB37ZVz3xwB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=H8GcymKJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jdelisle@gmail.com designates 2607:f8b0:4864:20::141 as permitted sender) smtp.mailfrom=jdelisle@gmail.com X-Spamd-Result: default: False [-2.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; NEURAL_HAM_LONG(-1.05)[-1.050]; NEURAL_SPAM_SHORT(0.09)[0.093]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::141:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 22:54:27 -0000 Nothing like making a good first-impression, right? On Wed, Jun 3, 2020 at 3:22 PM Jan Bramkamp wrote: > > On 03.06.20 22:18, Thomas Mueller wrote: > > from goatshit54108@national.shitposting.agency: > > > >> Once upon a time, the power ran out, and then... > >> ** SU+J Recovering /dev/<...> > >> ** Reading 33554432 byte journal from inode 4. > >> ** Building recovery table. > >> ** Resolving unreferenced inode list. > >> ** Processing journal entries. > >> fsck: /dev/<...>: Segmentation fault > > GAAAY. > > > >> OK, let's check the core dump... oh, wait... tough luck. Fortunately, > subsequent runs of fsck ended up likewise, so I was able to get a core dump > by re-executing fsck while being inside a TMPFS-backed directory. (On the > other hand, unfortunately, fsck was never able to replay the journal.) > Furthermore, I saved the .sujournal file, but saving the contents of the > whole filesystem was beyond my resources. (It would have been adequate to > use a tool that collected (only) the blocks that fsck read before > segfaulting (thus constructing a small test case), but no such tool was at > hand.) > >> Before running "fsck -y" (because I had no other options) I looked at > "fsck -n" to see whether a particular, large file would get idiotically > removed as part of "fixing" the filesystem. This routine is prompted by (1) > personal experiences of files getting lost or truncated to 0 length, and > (2) past reports of disasterous behaviors involving soft updates, such as > untouched (read-only) files getting lost; "lost" means not even relinked to > /lost+found or anything. And wouldn't ya know it, fsck did ask whether to > remove something that had an unambiguously large size (to be exact, IIRC: > "DUP ... REMOVE?", whatever that means). That's it, either (a) remove the > file, or (b) stay dirty; take it or leave it. It's not like there was some > 3rd option to relink the file to /lost+found. After "fsck -y", the file > disappeared without a trace. GAAAAAAAAAY. > > > >> The fsck_ffs (or fsck_ufs) file was the one distributed with the > 12.1-RELEASE, the one with the SHA3-256 checksum of > 447592ae05dc7829823901700bb90940968cae006719964d39b1212bb312d164. Let's see > the backtrace: > >> * thread #1, name = 'fsck_ufs', stop reason = signal SIGSEGV > >> * frame #0: 0x0000000000219d93 fsck_ffs`blk_free(bno=10692928, > mask=0, frags=134643471) at suj.c:653:34 > >> frame #1: 0x000000000021a481 fsck_ffs`ino_trunc(ino=5296913, > size=134610944) at suj.c:1547:3 > >> frame #2: 0x0000000000216fee fsck_ffs`suj_check [inlined] > cg_adj_blk(sc=0x0000000801574540) at suj.c:1788:5 > >> frame #3: 0x0000000000216fc3 fsck_ffs`suj_check [inlined] > cg_apply at suj.c:1900 > >> frame #4: 0x0000000000216fa5 > fsck_ffs`suj_check(filesys="/dev/<...>") at suj.c:2737 > >> frame #5: 0x000000000020ef54 fsck_ffs`main [inlined] > checkfilesys(filesys="/dev/<...>") at main.c:427:9 > >> frame #6: 0x000000000020ef07 fsck_ffs`main(argc=1, > argv=0x00007fffffffec48) at main.c:205 > >> frame #7: 0x000000000020810f fsck_ffs`_start(ap=, > cleanup=) at crt1.c:76:7 > >> Some analysis: > > (snip) > > > > I have had times when fsck_ffs from FreeBSD didn't succeed, but fsck_ffs > from NetBSD did succeed. That was on a FreeBSD installation, but I also > had/have NetBSD installed. > > > > I use GPT with no traditional BSD disklabels, so FreeBSD and NetBSD can > read and write each other's partitions. > > > > I ran "host national.shitposting.agency", and got > > > > national.shitposting.agency has address 52.11.159.5 > > national.shitposting.agency mail is handled by 20 mx2.cock.li. > > national.shitposting.agency mail is handled by 10 mx1.cock.li. > > > > so the domain really exists. > Yes as you can see in the MX records its run by a bunch of well known > racists and faschists who also brought us nice domains like > hitler.rocks, nigge.rs. nuke.africa and rape.lol. > _______________________________________________ > 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 Thu Jun 4 11:43:28 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 437363363CB for ; Thu, 4 Jun 2020 11:43:28 +0000 (UTC) (envelope-from large.hadron.collider@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49d3nW1kD9z4WPx for ; Thu, 4 Jun 2020 11:43:26 +0000 (UTC) (envelope-from large.hadron.collider@gmx.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1591271005; bh=SFnBP6xi+cscgFTLkLqJ07cBs/yRMxIQ1nvwF+nzmEM=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References; b=NmQJoaJ7NJdb27ZWYjy5NxLH1WWkUq2sb+y2DZGchNHQ2JVSbd29dIRcntd4h4RpI KAzyMN12nsDF/nz8iXdejna2ueV80CY449ewPaGas910Udc3Cag5Qo50BYqUip/+XL SGcJZVIegsyMn5/7f1+ku2YhOqDpvk8TdYDG0wdE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from Regeneratus.BC.CA.Umbrellix.NET ([50.69.229.17]) by mail.gmx.com (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MtfJX-1ipWCZ2BqR-00v59n for ; Thu, 04 Jun 2020 13:43:25 +0200 Date: Thu, 4 Jun 2020 04:43:22 -0700 From: Large Hadron Collider To: freebsd-fs@freebsd.org Subject: Re: fsck this shit Message-Id: <20200604044322.717fc55208d79bf8d3c66c6d@gmx.com> In-Reply-To: References: <2b976212-4c83-b528-3db6-aa8f5be4db4f@national.shitposting.agency> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:shB2eVpq0YSUgxwwL98WmmAb01wUUu2C+hZ7L4iphLHl1s7uAim 8wb7UB/8YW9HFsD7Mgy/RCwafEiT6nr/QJJjP7dVP26Diio8RioPL3vyupYUHzsZ2pdOtyT nTfyjFvsFir/RT5sQ1S6HO5bpwSr0ieRC+QZtrCOhn2t//uRhTMhNf3unSqDHOUuTuhbfV/ yaUG0IT6xTHY8fFvqlgyg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:SS30jaW1klM=:6fJ1sWgI2mopehZRlCG3pg RpBJEQ1pWCKoGhLaih35oIwezCqnLOIzM9acdCCe/RTmDNaBw23Lor51YZPLFKWLcYon8yLja XNWrNRiYANYHjWW6u1LZynXQCi3DS3V+k+6j6xJHxM96Z/AsevH3JFOKRpHHHXK6MjBorGAod GZRShm4ZkD05/OANBthuwCX7SQOuneCIkLPxlXx7HTS759hfjphSy7yDD0HYSXw/MABaltO9L Vsx3Ub2hytEQ7uPCVE4JETVq7GWKjF89Xrq0hd7xywtvrORCSMD367zT45LXvEirqmXEuZcYE gokcjHyk/1dJ9soTAN3wXS/g4fWvFPqmHAxLP/xNPO7jJWcJLaB9rGrQrYIvpL7bUAYxTb61/ ECKYe9eZNFuw9VHiB8C+/lPAEHCGjPO1T5fY2L/yUmy35MwSaoJZDYJk8neSHdVkaDL6x+V37 Au5eMVejpm/5UXpxqTiqv/Zz7VTCTeegjbaboe7/bdk4PJM8iILckyn42b0W66XmJPaJZUKfU JNjN4pbnt4lG9BORLSoEgph1AlWvlH8pbsPLhypxrwbjm9vLcxerT8ttbUuEpsiEc4JCPN/6T cgMalFm2ph+TlRaSB19XlJul7xepMXPKnOvFR+FvhM1B2XTnweDcFy3EeCRtoUQH90McOko5h BlitfvaKtPEVWkwSXbe8E5GETzKPn5IrnPo5jFlAN2onEO294gnxRMV1H1/TpkkvT+D/Lpqpx 0oiUB0Llp55rfWPViUTS55gY1ooPpqi3iyjo71CFRD7ADxE4zXm4k5wXGpjp3Y2JekjzD/edY 3LHBUFZ+tOkYL157KhH14Y+GU6L2d0Z/0qsuB63GGlMPTf8IUHjjStnXi0NB0c4e/aCzfjcL+ /EAOcM90ZaYkJEvef3Z1plf1YsanyKY9u8ptB5WNwSWxHPa97ULgPZOjYs7qFkuNoDBBxX8Nj G0hqy44pzduoVpN0v6ruj1tizbq3xxDWHEinjjiVqZ1NARQRQ4IDkTMBdN3MjlsKXcPjtMfb8 Y1ElmvQVyzQC91IrQpba56nHINPEFpZKE0USaxZLyKBIEGaE/pyPbr+U1YKHDRT2Ty1WNA6tz M05cdYEx5khUiv4XQM/N6Ui+HCuHPRXZrvfu4bCkAypaYlx31EuNbHxqwtncDVzLX0ick9hlB GI5EjKXAgAg+SSpo0mWrZ5u8cxrJ8ECSI526N9mieacFF8Qju9zs/Kgu5jHlukZsNw8gMbRtC oRDKQhe1Oj9oY1UqeSmEaEi3KVn3TEmym3MNpzQ== X-Rspamd-Queue-Id: 49d3nW1kD9z4WPx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=NmQJoaJ7; dmarc=none; spf=pass (mx1.freebsd.org: domain of large.hadron.collider@gmx.com designates 212.227.17.20 as permitted sender) smtp.mailfrom=large.hadron.collider@gmx.com X-Spamd-Result: default: False [-2.37 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmx.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; DKIM_TRACE(0.00)[gmx.net:+]; NEURAL_HAM_SHORT(-0.34)[-0.336]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.com]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.20:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.936]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[gmx.com]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.20:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 11:43:28 -0000 I doubt they're actually fascists or racists, but they certainly seem like= the kind of people to be sympathetic to fascists, racists and/or KKK memb= ers. On Wed, 3 Jun 2020 22:22:30 +0200 Jan Bramkamp wrote: > > On 03.06.20 22:18, Thomas Mueller wrote: > > from goatshit54108@national.shitposting.agency: > > > >> Once upon a time, the power ran out, and then... > >> ** SU+J Recovering /dev/<...> > >> ** Reading 33554432 byte journal from inode 4. > >> ** Building recovery table. > >> ** Resolving unreferenced inode list. > >> ** Processing journal entries. > >> fsck: /dev/<...>: Segmentation fault > > GAAAY. > > > >> OK, let's check the core dump... oh, wait... tough luck. Fortunately,= subsequent runs of fsck ended up likewise, so I was able to get a core du= mp by re-executing fsck while being inside a TMPFS-backed directory. (On t= he other hand, unfortunately, fsck was never able to replay the journal.) = Furthermore, I saved the .sujournal file, but saving the contents of the w= hole filesystem was beyond my resources. (It would have been adequate to u= se a tool that collected (only) the blocks that fsck read before segfaulti= ng (thus constructing a small test case), but no such tool was at hand.) > >> Before running "fsck -y" (because I had no other options) I looked at= "fsck -n" to see whether a particular, large file would get idiotically r= emoved as part of "fixing" the filesystem. This routine is prompted by (1)= personal experiences of files getting lost or truncated to 0 length, and = (2) past reports of disasterous behaviors involving soft updates, such as = untouched (read-only) files getting lost; "lost" means not even relinked t= o /lost+found or anything. And wouldn't ya know it, fsck did ask whether t= o remove something that had an unambiguously large size (to be exact, IIRC= : "DUP ... REMOVE?", whatever that means). That's it, either (a) remove th= e file, or (b) stay dirty; take it or leave it. It's not like there was so= me 3rd option to relink the file to /lost+found. After "fsck -y", the file= disappeared without a trace. GAAAAAAAAAY. > > > >> The fsck_ffs (or fsck_ufs) file was the one distributed with the 12.1= -RELEASE, the one with the SHA3-256 checksum of 447592ae05dc7829823901700b= b90940968cae006719964d39b1212bb312d164. Let's see the backtrace: > >> * thread #1, name =3D 'fsck_ufs', stop reason =3D signal SIGSEGV > >> * frame #0: 0x0000000000219d93 fsck_ffs`blk_free(bno=3D10692928, = mask=3D0, frags=3D134643471) at suj.c:653:34 > >> frame #1: 0x000000000021a481 fsck_ffs`ino_trunc(ino=3D5296913, = size=3D134610944) at suj.c:1547:3 > >> frame #2: 0x0000000000216fee fsck_ffs`suj_check [inlined] cg_ad= j_blk(sc=3D0x0000000801574540) at suj.c:1788:5 > >> frame #3: 0x0000000000216fc3 fsck_ffs`suj_check [inlined] cg_ap= ply at suj.c:1900 > >> frame #4: 0x0000000000216fa5 fsck_ffs`suj_check(filesys=3D"/dev= /<...>") at suj.c:2737 > >> frame #5: 0x000000000020ef54 fsck_ffs`main [inlined] checkfiles= ys(filesys=3D"/dev/<...>") at main.c:427:9 > >> frame #6: 0x000000000020ef07 fsck_ffs`main(argc=3D1, argv=3D0x0= 0007fffffffec48) at main.c:205 > >> frame #7: 0x000000000020810f fsck_ffs`_start(ap=3D= , cleanup=3D) at crt1.c:76:7 > >> Some analysis: > > (snip) > > > > I have had times when fsck_ffs from FreeBSD didn't succeed, but fsck_f= fs from NetBSD did succeed. That was on a FreeBSD installation, but I als= o had/have NetBSD installed. > > > > I use GPT with no traditional BSD disklabels, so FreeBSD and NetBSD ca= n read and write each other's partitions. > > > > I ran "host national.shitposting.agency", and got > > > > national.shitposting.agency has address 52.11.159.5 > > national.shitposting.agency mail is handled by 20 mx2.cock.li. > > national.shitposting.agency mail is handled by 10 mx1.cock.li. > > > > so the domain really exists. > Yes as you can see in the MX records its run by a bunch of well known > racists and faschists who also brought us nice domains like > hitler.rocks, nigge.rs. nuke.africa and rape.lol. > _______________________________________________ > 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" =2D- Large Hadron Collider From owner-freebsd-fs@freebsd.org Thu Jun 4 14:11:11 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ABCD62F4E04 for ; Thu, 4 Jun 2020 14:11:11 +0000 (UTC) (envelope-from achanler@gmail.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49d73y6Fmwz3f49 for ; Thu, 4 Jun 2020 14:11:10 +0000 (UTC) (envelope-from achanler@gmail.com) Received: by mail-ua1-x92c.google.com with SMTP id b13so2113210uav.3 for ; Thu, 04 Jun 2020 07:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kK5b/ioFOkWApzSMk1fYNTsqcp+WYIfpARwfm9PgUZk=; b=fevRjqegjAnY9WU4ytZONAOEMlNp8onyU7A7KxpSKCZshMAHcZnHFvbnJD8x77UtxY GqVKZawugSGnMo56lpZ04Hr1utrx6GUkVwsru8zeuITvIqe0dmFimJSU5Y5lq65je2wY bFJxZ3lvctcaTz7xQVHepGhivfseP8GgzeGqHXZd+28M5rZl54diW4bJ0+Dzg1tnu2oJ RHVROa2V1qXPA0OIyR0J3A2p/2ODpqD1DJx72Yd2g1okV91fAan8F00kA2NRqfcdLdZu nx0VytO3mMkhvKqMPRsohM6EX51tYU9r9HGBjK1lhrdU3nSJRWWse2Uw/4qcv2hUpuQd Hhig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kK5b/ioFOkWApzSMk1fYNTsqcp+WYIfpARwfm9PgUZk=; b=gJQ6Df03TwxCZ8BqsIz/nGEpRXPcgAdZn6bHupWqofLGzsK8LlWfid8ragH+dqKrH5 xl5lLtsRYafs1Pz1t9FJeJTx0iEtA5CZc6L54mi8ZyTuDsZhti4414URipBZYv91MzPr BoDIsty3zx3JE07ZCY9NukvNvZ/FyJY2Qv/PuevonD501p04i8rND1YpNpThL2H71rzq EmorftNRlZEgDN0af3Lra2PCpKaFSgmpB3nibLZguGhDhRWL3yJdiuOM5/q/Ug2i6psl vr49gJsnn4G+m6jU6UcR4hx2tc0+wIc2QNd2bZ60qusGyoqLUdEEAYFCwrKLivVtqloh 2a6g== X-Gm-Message-State: AOAM531TSAzd+KHf9UiunTVePt4J9ZG9M+qAu0gGjyk2wGVIwyd0tDq9 6Bjp55C5Dbd5V3GGBjasxG1JPEd3rW/DOSYSV5AYa+SUqXY= X-Google-Smtp-Source: ABdhPJw7FqB21DkxtB4Dwl1/AQaoyUEEmYc6JMVQdWN1hbxeU0g/SfubjYI7tmI9KdoCqDUAXsnHPMuPT9hi18llQ0c= X-Received: by 2002:ab0:2852:: with SMTP id c18mr3834729uaq.132.1591279869199; Thu, 04 Jun 2020 07:11:09 -0700 (PDT) MIME-Version: 1.0 From: Andrew Chanler Date: Thu, 4 Jun 2020 10:10:58 -0400 Message-ID: Subject: kernel panic loop after zpool remove To: freebsd-fs@freebsd.org X-Rspamd-Queue-Id: 49d73y6Fmwz3f49 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=fevRjqeg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of achanler@gmail.com designates 2607:f8b0:4864:20::92c as permitted sender) smtp.mailfrom=achanler@gmail.com X-Spamd-Result: default: False [-3.23 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.935]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.985]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92c:from]; NEURAL_HAM_SHORT(-0.31)[-0.309]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 14:11:11 -0000 Hi, Is there anyway to get zfs and the zpools into a recovery 'safe-mode' where it stops trying to do any manipulations of the zpools? I'm stuck in a kernel panic loop after 'zpool remove'. With the recent discussions about openzfs I was also considering trying to switch to openzfs but don't want to get myself into more trouble! I just need to stop the remove vdev operation and this 'metaslab free' code flow from running on the new vdev so I can keep the system up long enough to read the data out. Thank you, Andrew The system is running 'FreeBSD 12.1-RELEASE-p5 GENERIC amd64'. ------- panic: solaris assert: ((offset) & ((1ULL << vd->vdev_ashift) - 1)) == 0 (0x400 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c, line: 3593 cpuid = 1 time = 1590769420 KDB: stack backtrace: #0 0xffffffff80c1d307 at kdb_backtrace+0x67 #1 0xffffffff80bd063d at vpanic+0x19d #2 0xffffffff80bd0493 at panic+0x43 #3 0xffffffff82a6922c at assfail3+0x2c #4 0xffffffff828a3b83 at metaslab_free_concrete+0x103 #5 0xffffffff828a4dd8 at metaslab_free+0x128 #6 0xffffffff8290217c at zio_dva_free+0x1c #7 0xffffffff828feb7c at zio_execute+0xac #8 0xffffffff80c2fae4 at taskqueue_run_locked+0x154 #9 0xffffffff80c30e18 at taskqueue_thread_loop+0x98 #10 0xffffffff80b90c53 at fork_exit+0x83 #11 0xffffffff81082c2e at fork_trampoline+0xe Uptime: 7s ------- I have a core dump and can provide more details to help debug the issue and open a bug tracker too: ------- (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xffffffff80bd0238 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #3 0xffffffff80bd0699 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:877 #4 0xffffffff80bd0493 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:804 #5 0xffffffff82a6922c in assfail3 (a=, lv=, op=, rv=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #6 0xffffffff828a3b83 in metaslab_free_concrete (vd=0xfffff80004623000, offset=137438954496, asize=, checkpoint=0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:3593 #7 0xffffffff828a4dd8 in metaslab_free_dva (spa=, checkpoint=0, dva=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:3863 #8 metaslab_free (spa=, bp=0xfffff800043788a0, txg=41924766, now=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:4145 #9 0xffffffff8290217c in zio_dva_free (zio=0xfffff80004378830) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3070 #10 0xffffffff828feb7c in zio_execute (zio=0xfffff80004378830) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1786 #11 0xffffffff80c2fae4 in taskqueue_run_locked (queue=0xfffff80004222800) at /usr/src/sys/kern/subr_taskqueue.c:467 #12 0xffffffff80c30e18 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:773 #13 0xffffffff80b90c53 in fork_exit (callout=0xffffffff80c30d80 , arg=0xfffff800041d90b0, frame=0xfffffe004dcf9bc0) at /usr/src/sys/kern/kern_fork.c:1065 #14 (kgdb) frame 6 #6 0xffffffff828a3b83 in metaslab_free_concrete (vd=0xfffff80004623000, offset=137438954496, asize=, checkpoint=0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:3593 3593 VERIFY0(P2PHASE(offset, 1ULL << vd->vdev_ashift)); (kgdb) p /x offset $1 = 0x2000000400 (kgdb) p /x vd->vdev_ashift $2 = 0xc (kgdb) frame 9 #9 0xffffffff8290217c in zio_dva_free (zio=0xfffff80004378830) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3070 3070 metaslab_free(zio->io_spa, zio->io_bp, zio->io_txg, B_FALSE); (kgdb) p /x zio->io_spa->spa_root_vdev->vdev_child[0]->vdev_removing $3 = 0x1 (kgdb) p /x zio->io_spa->spa_root_vdev->vdev_child[0]->vdev_ashift $4 = 0x9 (kgdb) p /x zio->io_spa->spa_root_vdev->vdev_child[1]->vdev_ashift $5 = 0xc (kgdb) frame 8 #8 metaslab_free (spa=, bp=0xfffff800043788a0, txg=41924766, now=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:4145 4145 metaslab_free_dva(spa, &dva[d], checkpoint); (kgdb) p /x *bp $6 = {blk_dva = {{dva_word = {0x100000002, 0x10000002}}, {dva_word = {0x0, 0x0}}, {dva_word = {0x0, 0x0}}}, blk_prop = 0x8000020200010001, blk_pad = {0x0, 0x0}, blk_phys_birth = 0x0, blk_birth = 0x4, blk_fill = 0x0, blk_cksum = {zc_word = {0x0, 0x0, 0x0, 0x0}}} ------- Some of the notes on how I got in this state from the forum post ( https://forums.freebsd.org/threads/kernel-panic-loop-after-zpool-remove.75632/ ): I had two 2TB drives in mirror configuration for the last 7 years upgrading FreeBSD and zfs as time went by. I finally needed more storage and tried to add two 4TB drives as a second vdev mirror: 'zpool add storage mirror /dev/ada3 /dev/ada4' Next the 'zpool status' showed: --- pool: storage state: ONLINE status: One or more devices are configured to use a non-native block size. Expect reduced performance. action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool. scan: scrub repaired 0 in 0 days 08:39:28 with 0 errors on Sat May 9 01:19:54 2020 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 block size: 512B configured, 4096B native ada2 ONLINE 0 0 0 block size: 512B configured, 4096B native mirror-1 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada4 ONLINE 0 0 0 errors: No known data errors --- I should have stopped there, but saw the block size warning and thought I would try to fix it. The zdb showed mirror-0 with ashift 9 (512 byte alignment) and mirror-1 with ashift 12 (4096 byte alignment). I issued 'zpool remove storage mirror-0' and quickly went into a panic reboot loop. Rebooting into single user mode, first zfs or zpool command loads the driver and it panics again. Powering off the new drives and rebooting it does not panic, but it fails to because the zpool is missing a top-level vdev (mirror-1). From owner-freebsd-fs@freebsd.org Thu Jun 4 16:48:55 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BF1313297BA for ; Thu, 4 Jun 2020 16:48:55 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) Received: from mail.cock.li (mail.cock.li [37.120.193.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49dBYx1z2dz4GwK for ; Thu, 4 Jun 2020 16:48:52 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) To: freebsd-fs@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=national.shitposting.agency; s=mail; t=1591288754; bh=SkkQuYujo0QFwcH1V0Ok2sgMgP3dt8baIe+XZ15IGbg=; h=To:From:Subject:Date:From; b=nsjBhyxNIfL2uXk+P8b8C+Zt/Ol9qPKTDZ0KjTJdpopXtpGOPAIsIpSG0KJtqbVA+ vvmcfsiq/K5VK71s4jRYL4bK/3pKzAOSvrHgkFhLcX/Kp7W3L0tNDSx0mhD/egxBc2 xsNtpoltbYBLw6gSxhFQfBEYCjuvxH37Q4S1+zuTeODzo1lhdVG+pjpqRC0Ezh+Gw8 WVLMZNh7POzqHoo7mvD5cbCqfXHCNfCf940hWGrzTDBEmEbdbvuB7DVUZcaVPvDhWc KiVIQCCzSFX4JI9dtzhwnfHXzKHAaCuS0iE5E22VkdQsKwnzxbWn4Nzercy2zQfNI0 SUyBg/5/rHxOA== From: goatshit54108@national.shitposting.agency Subject: newfs(1) on a file Message-ID: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> Date: Thu, 4 Jun 2020 16:39:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.116 Safari/537.36 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49dBYx1z2dz4GwK X-Spamd-Bar: +++++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=national.shitposting.agency header.s=mail header.b=nsjBhyxN; dmarc=none; spf=fail (mx1.freebsd.org: domain of goatshit54108@national.shitposting.agency does not designate 37.120.193.124 as permitted sender) smtp.mailfrom=goatshit54108@national.shitposting.agency X-Spamd-Result: default: False [11.61 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; R_DKIM_ALLOW(0.00)[national.shitposting.agency:s=mail]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.63)[0.631]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shitposting.agency]; NEURAL_SPAM_MEDIUM(0.99)[0.993]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; VIOLATED_DIRECT_SPF(3.50)[]; DKIM_TRACE(0.00)[national.shitposting.agency:+]; NEURAL_SPAM_LONG(0.98)[0.984]; FROM_NO_DN(0.00)[]; FORGED_MUA_MOZILLA_MAIL_MSGID_UNKNOWN(2.50)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; RBL_SENDERSCORE(2.00)[37.120.193.124:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:9009, ipnet:37.120.193.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; GREYLIST(0.00)[pass,body] X-Spam: Yes X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 16:48:57 -0000 Running newfs(1) on a regular file bumps into some GAY issues: $ dd status=none if=/dev/zero bs=1m count=4 of=shit $ newfs ./shit newfs: ./shit: not a character-special device: No error: 0 newfs: no valid label found The message is not clear, but it happens to be a cry for a BSD label. OK, first creating a BSD label does allow newfs to succeed: $ bsdlabel -wf ./shit $ newfs ./shit newfs: ./shit: not a character-special device: No error: 0 ... (creation OK) The bump is inside getdisklabel(). Patching out the one and only call to getdisklabel() seems to avoid the issue without negative consequences: ... lp = NULL; //lp = getdisklabel(); // GAY ... $ dd status=none if=/dev/zero bs=1m count=4 of=shit $ non-gay_newfs ./shit newfs: ./shit: not a character-special device: No error: 0 preposterous size 0 $ non-gay_newfs -s $(((4 << 20) / 512)) ./shit newfs: ./shit: not a character-special device: No error: 0 ... (creation OK) The inconvenient alternative, to get newfs to format the file though a memory disk, appears to create an identical file: $ dd status=none if=/dev/zero bs=1m count=4 of=shit $ su root ... (GAY) ... # mdconfig -a -t vnode -f ./shit -u 9 # newfs /dev/md9 ... (creation OK) ... Identical, that is, if we use `newfs -R` and discount a couple of reproducibility bugs/issues (, ). Also, at a glance, using the BSD label method yields nothing other than a UFS filesystem along with a BSD label. So this code appears to be old garbage. Furthermore, the "not a character-special device" warning is just GAY without any benefit. Or?... From owner-freebsd-fs@freebsd.org Thu Jun 4 17:04:41 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 903E732A0E0 for ; Thu, 4 Jun 2020 17:04:41 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dBw84B5wz4Jpl for ; Thu, 4 Jun 2020 17:04:40 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Date: Thu, 04 Jun 2020 17:04:31 +0000 To: freebsd-fs@freebsd.org From: Nazim Can Bedir Reply-To: Nazim Can Bedir Subject: Re: newfs(1) on a file Message-ID: <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> In-Reply-To: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HK_RANDOM_REPLYTO shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49dBw84B5wz4Jpl X-Spamd-Bar: - X-Spamd-Result: default: False [-1.74 / 15.00]; HAS_REPLYTO(0.00)[nzmjx@protonmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.88)[-0.884]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.22:from]; NEURAL_HAM_MEDIUM(-0.08)[-0.083]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_SPAM_SHORT(0.32)[0.325]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.22:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 17:04:41 -0000 Or, The normal file I/O and device I/O call and code paths in the kernel are=20 different. And, in order to include efficient and proper caching of disk=20 blocks into the equation, damn filesystem backing stores need to be=20 exist as devices. And, contrary to common belief, FreeBSD kernel=20 developers may not be smart enough as you because they followed the sane=20 approach: if mount command couldn't mount a GAY filesystem from the file=20 as-is, then newfs(8) command shouldn't allow to create filesystem on=20 file as-is (otherwise, idiot FreeBSD users like me could think that=20 "aah, if newfs initialises filesystem on file without md, then it must=20 be able to mount without md). I really don't understand what is the damn problem here? Filesystem=20 operations are performed on special files (a.k.a disks); and md kernel=20 driver does exist for that purpose. On 04/06/2020 19:39, goatshit54108@national.shitposting.agency wrote: > Running newfs(1) on a regular file bumps into some GAY issues: > > $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit > $ newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > newfs: no valid label found > > The message is not clear, but it happens to be a cry for a BSD label. OK,= first creating a BSD label does allow newfs to succeed: > $ bsdlabel -wf ./shit > $ newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > ... (creation OK) > > The bump is inside getdisklabel(). Patching out the one and only call to = getdisklabel() seems to avoid the issue without negative consequences: > =09... > =09lp =3D NULL; //lp =3D getdisklabel(); // GAY > =09... > > $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit > $ non-gay_newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > preposterous size 0 > $ non-gay_newfs -s $(((4 << 20) / 512)) ./shit > newfs: ./shit: not a character-special device: No error: 0 > ... (creation OK) > > The inconvenient alternative, to get newfs to format the file though a me= mory disk, appears to create an identical file: > $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit > $ su root > ... (GAY) ... > # mdconfig -a -t vnode -f ./shit -u 9 > # newfs /dev/md9 > ... (creation OK) ... > > Identical, that is, if we use `newfs -R` and discount a couple of reprodu= cibility bugs/issues (, ). > > Also, at a glance, using the BSD label method yields nothing other than a= UFS filesystem along with a BSD label. > > So this code appears to be old garbage. > > Furthermore, the "not a character-special device" warning is just GAY wit= hout any benefit. > > Or?... > _______________________________________________ > 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 Thu Jun 4 18:51:41 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6400432CDEA for ; Thu, 4 Jun 2020 18:51:41 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dFHc4f6jz4YD1 for ; Thu, 4 Jun 2020 18:51:40 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-il1-x134.google.com with SMTP id p5so7131603ile.6 for ; Thu, 04 Jun 2020 11:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kjO0NFobSUpe3gcf7p1uWnCL7NXpuugIKj/W/h9rcMI=; b=mEFbBfOayDfpyrCaI/bhfi7k66SlV/vUDemEdc7d5nUvNjzLjUwU38MT/2TGLFxfEs vXhCzCUVKZOfvjgMnjgCpBIYaKxLBbZMZ0AgeucMZkxN6q56lI+QrJSWairop+V7SveJ oipQNKwL6rAbUJiAdvVWj+HYNDTXGJh0KMav0ZvdEqQLyYoH77RMk/xeI6B+wOrM/bTb nU5MfkaseXg0l/f0XVyRI1ZaHPzuCbIi1RIxQxlP9j5BrqhUcJJFP04/9i5EMqyXWbMy xR9xr5525uRWzEosyEH/UTnnkvJvMqH0PIxnCgwFztOliJWFszobc71lJdv7An/6u0Av Hqpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kjO0NFobSUpe3gcf7p1uWnCL7NXpuugIKj/W/h9rcMI=; b=esccw3tkpPsK7hRWSjugQyAt3nB6+7Gg+7bkfNrzOLJNA+cUg/+TCrz0bAne4QVgQT XlijqdLeLYcOgLyqj3Tt7izKlCRhtC+2PzgE6Jk19mTj1Mbzsr6yaeh9+SlN8sGx9Lyx f5ESUJLNot93uI4ueCOyBWLjL9onyozWWW0iJYbyMB3byhH8BJmkDV2hvHXwfzonJfNI 0Ywb9HIpPs+0CEq6w7CfCZIQO5e0syGkqH/0nSSco/RG/7f4saBFvYtrezO+VEB0yUDE EjMjE3VxGjC8UY146lEAMAhw++4OnYO9bleTSkTY/BwtUmqzSiL+n8ymkxuB9ApO+CPP Ra2A== X-Gm-Message-State: AOAM533dUCk6cvhiMPgrrHYBMpF9aVsOJ1cTs6C42CBut0gMtF+R0bM0 lmHBbkf8VHXG5v4FTPghqYnWh8d4+2anGPIzdOmkGYj/ X-Google-Smtp-Source: ABdhPJxto3RZSsVgXv1plbCxoSfDDeLxIJr3YReP99pJOHEd/yApNh+R1QaKlxCH0YQFGr89ZNdzIUiC/j0YtPruOkE= X-Received: by 2002:a05:6e02:eb0:: with SMTP id u16mr5535276ilj.81.1591296699451; Thu, 04 Jun 2020 11:51:39 -0700 (PDT) MIME-Version: 1.0 References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> In-Reply-To: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> From: Aryeh Friedman Date: Thu, 4 Jun 2020 14:51:27 -0400 Message-ID: Subject: Re: newfs(1) on a file To: goatshit54108@national.shitposting.agency Cc: freebsd-fs@freebsd.org X-Rspamd-Queue-Id: 49dFHc4f6jz4YD1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mEFbBfOa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of aryehfriedman@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) smtp.mailfrom=aryehfriedman@gmail.com X-Spamd-Result: default: False [-2.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.01)[-1.005]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_SHORT(0.03)[0.031]; NEURAL_HAM_LONG(-0.99)[-0.985]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::134:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 18:51:41 -0000 Top posting since the comment has very little to do with the actual content of the message. I am amazed people call me a troll but someone who is purposely being one is not called out?!?!!? How many of the posting guidelines has this guy broken already? On Thu, Jun 4, 2020 at 12:49 PM wrote: > Running newfs(1) on a regular file bumps into some GAY issues: > > $ dd status=none if=/dev/zero bs=1m count=4 of=shit > $ newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > newfs: no valid label found > > The message is not clear, but it happens to be a cry for a BSD label. OK, > first creating a BSD label does allow newfs to succeed: > $ bsdlabel -wf ./shit > $ newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > ... (creation OK) > > The bump is inside getdisklabel(). Patching out the one and only call to > getdisklabel() seems to avoid the issue without negative consequences: > ... > lp = NULL; //lp = getdisklabel(); // GAY > ... > > $ dd status=none if=/dev/zero bs=1m count=4 of=shit > $ non-gay_newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > preposterous size 0 > $ non-gay_newfs -s $(((4 << 20) / 512)) ./shit > newfs: ./shit: not a character-special device: No error: 0 > ... (creation OK) > > The inconvenient alternative, to get newfs to format the file though a > memory disk, appears to create an identical file: > $ dd status=none if=/dev/zero bs=1m count=4 of=shit > $ su root > ... (GAY) ... > # mdconfig -a -t vnode -f ./shit -u 9 > # newfs /dev/md9 > ... (creation OK) ... > > Identical, that is, if we use `newfs -R` and discount a couple of > reproducibility bugs/issues (< > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246983>, < > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246985>). > > Also, at a glance, using the BSD label method yields nothing other than a > UFS filesystem along with a BSD label. > > So this code appears to be old garbage. > > Furthermore, the "not a character-special device" warning is just GAY > without any benefit. > > Or?... > _______________________________________________ > 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" > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-fs@freebsd.org Thu Jun 4 18:56:30 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC81F32D20F for ; Thu, 4 Jun 2020 18:56:30 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dFP96Hlfz4YZv for ; Thu, 4 Jun 2020 18:56:29 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Date: Thu, 04 Jun 2020 18:56:17 +0000 To: freebsd-fs@freebsd.org From: Nazim Can Bedir Reply-To: Nazim Can Bedir Subject: Re: newfs(1) on a file Message-ID: <475e7bb7-399f-4c32-ae67-b31a62e70455@protonmail.com> In-Reply-To: References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HK_RANDOM_REPLYTO shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49dFP96Hlfz4YZv X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.21 / 15.00]; HAS_REPLYTO(0.00)[nzmjx@protonmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.89)[-0.886]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from]; NEURAL_HAM_MEDIUM(-0.09)[-0.087]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.13)[-0.133]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.134:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 18:56:31 -0000 No my friend, he is not trolling but shit-posting. Please let pay attention to details, because devil lies in details. On 04/06/2020 21:51, Aryeh Friedman wrote: > Top posting since the comment has very little to do with the actual conte= nt > of the message. I am amazed people call me a troll but someone who is > purposely being one is not called out?!?!!? How many of the posting > guidelines has this guy broken already? > > On Thu, Jun 4, 2020 at 12:49 PM > wrote: > >> Running newfs(1) on a regular file bumps into some GAY issues: >> >> $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit >> $ newfs ./shit >> newfs: ./shit: not a character-special device: No error: 0 >> newfs: no valid label found >> >> The message is not clear, but it happens to be a cry for a BSD label. OK= , >> first creating a BSD label does allow newfs to succeed: >> $ bsdlabel -wf ./shit >> $ newfs ./shit >> newfs: ./shit: not a character-special device: No error: 0 >> ... (creation OK) >> >> The bump is inside getdisklabel(). Patching out the one and only call to >> getdisklabel() seems to avoid the issue without negative consequences: >> ... >> lp =3D NULL; //lp =3D getdisklabel(); // GAY >> ... >> >> $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit >> $ non-gay_newfs ./shit >> newfs: ./shit: not a character-special device: No error: 0 >> preposterous size 0 >> $ non-gay_newfs -s $(((4 << 20) / 512)) ./shit >> newfs: ./shit: not a character-special device: No error: 0 >> ... (creation OK) >> >> The inconvenient alternative, to get newfs to format the file though a >> memory disk, appears to create an identical file: >> $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit >> $ su root >> ... (GAY) ... >> # mdconfig -a -t vnode -f ./shit -u 9 >> # newfs /dev/md9 >> ... (creation OK) ... >> >> Identical, that is, if we use `newfs -R` and discount a couple of >> reproducibility bugs/issues (< >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246983>, < >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246985>). >> >> Also, at a glance, using the BSD label method yields nothing other than = a >> UFS filesystem along with a BSD label. >> >> So this code appears to be old garbage. >> >> Furthermore, the "not a character-special device" warning is just GAY >> without any benefit. >> >> Or?... >> _______________________________________________ >> 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" >> > > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > _______________________________________________ > 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 Thu Jun 4 19:03:33 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 85AAA32D610 for ; Thu, 4 Jun 2020 19:03:33 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dFYJ0tPgz4ZQ4 for ; Thu, 4 Jun 2020 19:03:31 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-il1-x12e.google.com with SMTP id t8so7161776ilm.7 for ; Thu, 04 Jun 2020 12:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UtR1DvL5Dc17YXkT5QloUQD28LHORGlba+ROasoRfE4=; b=X43QecWBjBUmHz0/ACb5SSTjGs1Rx/eQDZHeaP+470oJs/olpAujdeMgnL8zZvAuOl iV7brD5OTIg4oszxPkCFqL+b8rpk+ck0wFmNtVxBpVvVSHXSkg0ROB+SYMRvZd2b4kmk 2eltrzWAf3woUPiPEb3yrkwwDN+J/CZCtpq7t+Wxru63EFbxS0vIqT7Y7Ki3vMgLEZ4d mcR1Jp8uVbf6SdYXm9bpUNKKlhuxUOVwQo3XclVOHJG0ciir2zr7X1wO6X0cBp3e3WeQ 4jwO82oTKQ90ezEszJqK+sKkg7cdrDAk32ywoV9QZDxUngF4HachMpOMokWoXXJ+jquC HeGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UtR1DvL5Dc17YXkT5QloUQD28LHORGlba+ROasoRfE4=; b=WB9g+arUm1iV6CmoKLjioQaDW/Il+jqDUY7Ksc96zjtsS9TOOMvgLW+h4kFUEzpq/n 9qPgtNYi57buQCJs1HYEGFnJtj+4ul/QSRNtJcIh6YIuT5OZzY3NIU89DzCsDkbboWj5 tPuHQh9CKz88QLCXFQFU9zDsq6edfmYHebVKV72z/DTO/TURfAGPr76wZsTsZam0tcoZ cbAbayWZiR1QZMCoTcW+WzNeyqbWrDQ8mNYr9wAjOXHnfk6wsXb6Z1YEetSZl0qgrSNF gY7+FkXrk1cBEoIrEQTF9UmkT0L88KRxLVz4X/zAR+O3/iD3LG1lGAsxS8be+tJa76Po /7gA== X-Gm-Message-State: AOAM530N1sf1WaJFla+u6YoLIkMrIrU5L+24xd23sCywVDubbvxFYwUj nKbh6IqnjpjAsH3SdPhXC+R52M8/u5hCBDWvDFi5IdUx X-Google-Smtp-Source: ABdhPJxQN1qZeT1ofZV6SOSQa8k1dtx7/CEwLF7wzPbuSIBEzpL5ERPrnfV27ixHDhL/2oj7vWU/WNtAONEhVqeX37U= X-Received: by 2002:a05:6e02:eb0:: with SMTP id u16mr5576086ilj.81.1591297411123; Thu, 04 Jun 2020 12:03:31 -0700 (PDT) MIME-Version: 1.0 References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <475e7bb7-399f-4c32-ae67-b31a62e70455@protonmail.com> In-Reply-To: <475e7bb7-399f-4c32-ae67-b31a62e70455@protonmail.com> From: Aryeh Friedman Date: Thu, 4 Jun 2020 15:03:19 -0400 Message-ID: Subject: Re: newfs(1) on a file To: Nazim Can Bedir Cc: freebsd-fs@freebsd.org X-Rspamd-Queue-Id: 49dFYJ0tPgz4ZQ4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=X43QecWB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of aryehfriedman@gmail.com designates 2607:f8b0:4864:20::12e as permitted sender) smtp.mailfrom=aryehfriedman@gmail.com X-Spamd-Result: default: False [-2.84 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; NEURAL_HAM_LONG(-0.96)[-0.965]; NEURAL_SPAM_SHORT(0.12)[0.121]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12e:from]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 19:03:33 -0000 On Thu, Jun 4, 2020 at 2:56 PM Nazim Can Bedir via freebsd-fs < freebsd-fs@freebsd.org> wrote: > No my friend, he is not trolling but shit-posting. > > Please let pay attention to details, because devil lies in details. > The posting guidelines and the foundation code of conduct say you may not insult anyone's sexual identity by using "gay" to be an insult he is doing just that. So that is not trolling? He is also complaining about something that is specifically not recommended in the handbook (not using md first). So how is that not two counts of trolling (1 count for not reading the handbook first and 1 for purposely doing stuff the wrong way to be nothing but annoying). -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-fs@freebsd.org Thu Jun 4 19:12:39 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3751332DB83 for ; Thu, 4 Jun 2020 19:12:39 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dFlp32WBz4bs6 for ; Thu, 4 Jun 2020 19:12:37 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Date: Thu, 04 Jun 2020 19:12:30 +0000 To: Aryeh Friedman From: Nazim Can Bedir Cc: freebsd-fs@freebsd.org Reply-To: Nazim Can Bedir Subject: Re: newfs(1) on a file Message-ID: <58249490-56d6-e35a-4a21-7afdf343324b@protonmail.com> In-Reply-To: References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <475e7bb7-399f-4c32-ae67-b31a62e70455@protonmail.com> MIME-Version: 1.0 X-Spam-Status: No, score=-0.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HK_RANDOM_REPLYTO, HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49dFlp32WBz4bs6 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.75 / 15.00]; HAS_REPLYTO(0.00)[nzmjx@protonmail.com]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c]; FREEMAIL_FROM(0.00)[protonmail.com]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.78)[-0.782]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.134:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.006]; TAGGED_RCPT(0.00)[]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 19:12:39 -0000 Q29tZSBvbiwgbXkgcmVzcG9uc2UgdG8geW91IHdhcyBqdXN0IGEgc2FyY2FzbS4gT2YgY291cnNl LCBoZSBkaWQgcGVyZm9ybSBsaWtlIGFuIGltbWF0dXJlLCBob21vcGhvYmljLCByYWNpc3QgbW9y b247IGJ1dCBoZXksIGhlIGRvZXNuJ3QgaGF2ZSB0aGUgbW9zdCBpbXBvcnRhbnQgb3JnYW46IGJy YWluIQoKSSB3YXNuJ3Qgb24gbGlzdCB3aGVuIHRoZXkgdHJlYXRlZCB5b3UgYXMgeW91IGRlc2Ny aWJlZDsgc28gSSBjYW4ndCB0ZWxsIGFueXRoaW5nLiBCdXQgSSBjYW4gYXNzdXJlIHRoYXQgYWZ0 ZXIgb25lIChhbmQgb25seSBvbmUpIHJlc3BvbnNlLCBpZiBoZSBzdGlsbCBjb250aW51ZXMgYXMg aGUgZG9lczsgc29tZSBwZW9wbGUgd2lsbCB0ZWFjaCBoaW0gaG93IHRvIGJlaGF2ZS4gSWYgbm90 LCBzdGlsbCBubyB3b3JyaWVzOyBiZWNhdXNlIHRoaXMgbGlzdCBiZWxvbmdzIHRvIGEgZm91bmRh dGlvbiBhbmQgdGhlcmUgaXMgYWx3YXlzIHNvbWVvbmUgdG8gZmlsZSBhIGNvbXBsYWludC4KCkNo ZWVycyEKCk9uIDA0LzA2LzIwMjAgMjI6MDMsIEFyeWVoIEZyaWVkbWFuIHdyb3RlOgoKPiBPbiBU aHUsIEp1biA0LCAyMDIwIGF0IDI6NTYgUE0gTmF6aW0gQ2FuIEJlZGlyIHZpYSBmcmVlYnNkLWZz IDxmcmVlYnNkLWZzQGZyZWVic2Qub3JnPiB3cm90ZToKPgo+PiBObyBteSBmcmllbmQsIGhlIGlz IG5vdCB0cm9sbGluZyBidXQgc2hpdC1wb3N0aW5nLgo+Pgo+PiBQbGVhc2UgbGV0IHBheSBhdHRl bnRpb24gdG8gZGV0YWlscywgYmVjYXVzZSBkZXZpbCBsaWVzIGluIGRldGFpbHMuCj4KPiBUaGUg cG9zdGluZyBndWlkZWxpbmVzIGFuZCB0aGUgZm91bmRhdGlvbiBjb2RlIG9mIGNvbmR1Y3Qgc2F5 IHlvdSBtYXkgbm90IGluc3VsdCBhbnlvbmUncyBzZXh1YWwgaWRlbnRpdHkgYnkgdXNpbmcgImdh eSIgdG8gYmUgYW4gaW5zdWx0IGhlIGlzIGRvaW5nIGp1c3QgdGhhdC4gICBTbyB0aGF0IGlzIG5v dCB0cm9sbGluZz8gICBIZSBpcyBhbHNvIGNvbXBsYWluaW5nIGFib3V0IHNvbWV0aGluZyB0aGF0 IGlzIHNwZWNpZmljYWxseSBub3QgcmVjb21tZW5kZWQgaW4gdGhlIGhhbmRib29rIChub3QgdXNp bmcgbWQgZmlyc3QpLiAgIFNvIGhvdyBpcyB0aGF0IG5vdCB0d28gY291bnRzIG9mIHRyb2xsaW5n ICgxIGNvdW50IGZvciBub3QgcmVhZGluZyB0aGUgaGFuZGJvb2sgZmlyc3QgYW5kIDEgZm9yIHB1 cnBvc2VseSBkb2luZyBzdHVmZiB0aGUgd3Jvbmcgd2F5IHRvIGJlIG5vdGhpbmcgYnV0IGFubm95 aW5nKS4KPiAtLQo+Cj4gQXJ5ZWggTS4gRnJpZWRtYW4sIExlYWQgRGV2ZWxvcGVyLCBodHRwOi8v d3d3LlBldGl0ZUNsb3VkLm9yZw== From owner-freebsd-fs@freebsd.org Thu Jun 4 21:14:27 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5B90B3322C0 for ; Thu, 4 Jun 2020 21:14:27 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) Received: from mail.cock.li (mail.cock.li [37.120.193.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49dJSL13twz3gtp for ; Thu, 4 Jun 2020 21:14:25 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) Subject: Re: newfs(1) on a file DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=national.shitposting.agency; s=mail; t=1591305262; bh=ijpFJP2S0akwV+wLVYwEufEVaTCex9cgWlKbbRCXZeY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eHGGdmNosDQkeuBIr+IarYsPFnlWzPA8bo2MJqtkDPJ0EnDMkDvlxRAvrhgyeFCRI b2FXdygvIeW7cFYFNk3xU6gJBEEJnXIsURGZUJWqQGdafBodpLRceB5+OdsoaeQuh2 NQBMxbqRxlItoKLNKmVgi31hwfTAV7q3zGgbybPrIH8fWDNDQNwdV9yfAzVSDX3b9i 9HrlfNRH64gYljb85NWGKw8oo5r34vtrsVY3WVpDc7q+OESj7o42zM72Qc4TG6sOQD xERW614fMqCnRF6cNPDS+LZs/BXjuvJqo3TkkfP9Wz5aCH8JjOP9nubdyqoVGC23KN pUuVXB5IjxDLA== To: freebsd-fs@freebsd.org References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> From: goatshit54108@national.shitposting.agency Message-ID: Date: Thu, 4 Jun 2020 21:14:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.116 Safari/537.36 MIME-Version: 1.0 In-Reply-To: <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49dJSL13twz3gtp X-Spamd-Bar: +++++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=national.shitposting.agency header.s=mail header.b=eHGGdmNo; dmarc=none; spf=fail (mx1.freebsd.org: domain of goatshit54108@national.shitposting.agency does not designate 37.120.193.124 as permitted sender) smtp.mailfrom=goatshit54108@national.shitposting.agency X-Spamd-Result: default: False [11.98 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; R_DKIM_ALLOW(0.00)[national.shitposting.agency:s=mail]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.990]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shitposting.agency]; NEURAL_SPAM_MEDIUM(1.00)[1.002]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; VIOLATED_DIRECT_SPF(3.50)[]; DKIM_TRACE(0.00)[national.shitposting.agency:+]; NEURAL_SPAM_LONG(0.99)[0.987]; FROM_NO_DN(0.00)[]; FORGED_MUA_MOZILLA_MAIL_MSGID_UNKNOWN(2.50)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; RBL_SENDERSCORE(2.00)[37.120.193.124:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:9009, ipnet:37.120.193.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; GREYLIST(0.00)[pass,meta] X-Spam: Yes X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 21:14:27 -0000 On 6/4/20 5:04 PM, Nazim Can Bedir via freebsd-fs wrote: > in order to include efficient and proper caching of disk > blocks into the equation, damn filesystem backing stores need to be > exist as devices. I find that hard to believe, at least with that exact wording. An alternative "Sorry, but all current FreeBSD-kernel filesystem-code is designed only with underlying block devices in mind, so some work is needed to handle other cases." sounds acceptable. The caching strategy mainly depends on the filesystem type, its implementation, and the settings. For some "filesystems", such as swap spaces, caching is specifically to be avoided. Linux is able to perform `swapon ./file`, FreeBSD isn't. > if mount command couldn't mount a GAY filesystem from the file > as-is, then newfs(8) command shouldn't allow to create filesystem on > file as-is (otherwise, idiot FreeBSD users like me could think that > "aah, if newfs initialises filesystem on file without md, then it must > be able to mount without md). But newfs *is* able to create a filesystem on a regular file. > I really don't understand what is the damn problem here? Filesystem > operations are performed on special files (a.k.a disks); and md kernel > driver does exist for that purpose. Again, I don't like this way of thinking. First, it goes again the Unix philosophy. Second, there is a clear separation between (a) creating, attempting to repair or debugging an instance of a filesystem, and (b) mounting a filesystem, thus connecting it to the kernel's filesystem-system -- a highly flammable area --, which practically assumes that the instance is well-formatted, and demands exclusive write access. From owner-freebsd-fs@freebsd.org Thu Jun 4 21:20:21 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 16728332A02 for ; Thu, 4 Jun 2020 21:20:21 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dJb76pDnz3yhn for ; Thu, 4 Jun 2020 21:20:19 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Date: Thu, 04 Jun 2020 21:20:11 +0000 To: freebsd-fs@freebsd.org From: Nazim Can Bedir Reply-To: Nazim Can Bedir Subject: Re: newfs(1) on a file Message-ID: <1e6f811b-768b-0382-ff7e-54f0128cb876@protonmail.com> In-Reply-To: References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HK_RANDOM_REPLYTO shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49dJb76pDnz3yhn X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.24 / 15.00]; HAS_REPLYTO(0.00)[nzmjx@protonmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.89)[-0.890]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.22:from]; NEURAL_HAM_MEDIUM(-0.09)[-0.091]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.15)[-0.154]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.22:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 21:20:21 -0000 Linux is able to perform `swapon ./file`, FreeBSD isn't. Then, go fuck and use Linux. No body gives a shit about you and your=20 fucking preferred system. And, stay with Linux: asshole! Again, I don't like this way of thinking. First, it goes again the Unix phi= losophy. Second, there is a clear separation between (a) creating, attempti= ng to repair or debugging an instance of a filesystem, and (b) mounting a f= ilesystem, thus connecting it to the kernel's filesystem-system -- a highly= flammable area --, which practically assumes that the instance is well-for= matted, and demands exclusive write access. Then, your problem is you are trying to live in a world where you don't=20 understand. It doesn't work in real life, and it doesn't work in Unix=20 either. So, go fuck yourself. Did I say "Go fuck yourself, and never come back!"? Sorry, I am not=20 smart enough. If my country there is a saying: "If you know better, then prove it. At=20 least, we can use the better one." Otherwise, shut the fuck up and find=20 another list to shit-post! In this list, there is only one dick who can=20 shit-post and guess who he is? So, seriously my friend, FUCK OFF! Regards, Nazim Can. On 05/06/2020 00:14, goatshit54108@national.shitposting.agency wrote: > On 6/4/20 5:04 PM, Nazim Can Bedir via freebsd-fs wrote: >> in order to include efficient and proper caching of disk >> blocks into the equation, damn filesystem backing stores need to be >> exist as devices. > I find that hard to believe, at least with that exact wording. An alterna= tive "Sorry, but all current FreeBSD-kernel filesystem-code is designed onl= y with underlying block devices in mind, so some work is needed to handle o= ther cases." sounds acceptable. > > The caching strategy mainly depends on the filesystem type, its implement= ation, and the settings. For some "filesystems", such as swap spaces, cachi= ng is specifically to be avoided. > > Linux is able to perform `swapon ./file`, FreeBSD isn't. > >> if mount command couldn't mount a GAY filesystem from the file >> as-is, then newfs(8) command shouldn't allow to create filesystem on >> file as-is (otherwise, idiot FreeBSD users like me could think that >> "aah, if newfs initialises filesystem on file without md, then it must >> be able to mount without md). > But newfs *is* able to create a filesystem on a regular file. > >> I really don't understand what is the damn problem here? Filesystem >> operations are performed on special files (a.k.a disks); and md kernel >> driver does exist for that purpose. > Again, I don't like this way of thinking. First, it goes again the Unix p= hilosophy. Second, there is a clear separation between (a) creating, attemp= ting to repair or debugging an instance of a filesystem, and (b) mounting a= filesystem, thus connecting it to the kernel's filesystem-system -- a high= ly flammable area --, which practically assumes that the instance is well-f= ormatted, and demands exclusive write access. > _______________________________________________ > 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 Thu Jun 4 21:24:38 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9FE8E332969 for ; Thu, 4 Jun 2020 21:24:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dJh55267z40PC for ; Thu, 4 Jun 2020 21:24:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id w3so7740987qkb.6 for ; Thu, 04 Jun 2020 14:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2OGwHfORPv2p1+dWb6AKCxdesrv03fX00+ruHk64Haw=; b=UIudO9tF45G6FFvYy416E2wkRSft997CQQqolrYJWDQ4Xp9N5zvCCSi38+0HpsP3aE j+j4aGZbVwtG01GqXb9z5rShbMoW3zlv49m+zbz6TbjkP9PT2b/CqsBjWPjIxzZzNx8w sJJxLneSFgPM9TxyF4IHPrqNutSzWr4+6OM0E4Dlo3h+wVSIW630lTmuRxcFhmuBJODL Rv1n/UZMmyf+eMgo/UK8HSYTkWgmlEGYNVJZuqSap9UwjX7HIasEEuyTLbUo8PNRKlki +W+x191tVPIiqGWDctYz2V2AK7dwVrrgdxrQmiWUn0TFkKlmjCMbkDQrqmPoH1rWf5ZI ++lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2OGwHfORPv2p1+dWb6AKCxdesrv03fX00+ruHk64Haw=; b=ANmEVC/C4wKL9dbbdmfbi+zJH4uFnyW36hj0KHmJ7eYAHiJeFoZP4stzhmWhlftVo2 XUl7kfV7cSNa6myQOfh3p/NbETCSMWlkZ/ugUTbNW9lZYqd0RSf2xqqhclQOtnpnaxiO dtpoibtWPXK1ODRJb7olbxN93LoQuQ528wEOUMMVzvMNDRcnSrwipl6UAnUFE7FZSYQe FK/p0r3t4NozHJGKv4n/mqzbMqS7uuUIGJINqpaRqfG9vyuPwb0gLeF2qXgayU8JgINX 7vStDMOQlJP33cshlZijZ9rVJhQ9h6SzHLWAWsXI3wbMF4gpARJYxi+fSI5H8isWBB6z qFiQ== X-Gm-Message-State: AOAM531AS5ZlXK8QxXHk4vnO9lbsoHlQWu61MbIP0WqAznMsQeb2sbdv esK2uCl61dGhSikAb/2849jZIHGFvt+87lfeNuJsP3YV X-Google-Smtp-Source: ABdhPJxeJ2y2i7PnUicf/TPZ7rHOoAHE6+VTWC5YXUZLkhgBzm4vnFfDHLBMtb3IHUj/KKr3J838uYsjHCcT9QV+66Q= X-Received: by 2002:a37:5c47:: with SMTP id q68mr6595935qkb.495.1591305876681; Thu, 04 Jun 2020 14:24:36 -0700 (PDT) MIME-Version: 1.0 References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> In-Reply-To: From: Warner Losh Date: Thu, 4 Jun 2020 15:24:25 -0600 Message-ID: Subject: Re: newfs(1) on a file To: goatshit54108@national.shitposting.agency Cc: FreeBSD FS X-Rspamd-Queue-Id: 49dJh55267z40PC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=UIudO9tF; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::730) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.01 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.00)[0.004]; NEURAL_HAM_LONG(-1.00)[-1.001]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 21:24:38 -0000 On Thu, Jun 4, 2020 at 3:14 PM wrote: > On 6/4/20 5:04 PM, Nazim Can Bedir via freebsd-fs wrote: > > in order to include efficient and proper caching of disk > > blocks into the equation, damn filesystem backing stores need to be > > exist as devices. > > I find that hard to believe, at least with that exact wording. An > alternative "Sorry, but all current FreeBSD-kernel filesystem-code is > designed only with underlying block devices in mind, so some work is needed > to handle other cases." sounds acceptable. > > The caching strategy mainly depends on the filesystem type, its > implementation, and the settings. For some "filesystems", such as swap > spaces, caching is specifically to be avoided. > > Linux is able to perform `swapon ./file`, FreeBSD isn't. > echp | dd oseek=10000 count=1 of=fred swapon /dev/$(mdconfig -f fred) Does the trick. > > if mount command couldn't mount a GAY filesystem from the file > > as-is, then newfs(8) command shouldn't allow to create filesystem on > > file as-is (otherwise, idiot FreeBSD users like me could think that > > "aah, if newfs initialises filesystem on file without md, then it must > > be able to mount without md). > > But newfs *is* able to create a filesystem on a regular file. > It's a bug, born from a long legacy of needing the information in the disklabel in the past. That requirement has passed... > > I really don't understand what is the damn problem here? Filesystem > > operations are performed on special files (a.k.a disks); and md kernel > > driver does exist for that purpose. > > Again, I don't like this way of thinking. First, it goes again the Unix > philosophy. Second, there is a clear separation between (a) creating, > attempting to repair or debugging an instance of a filesystem, and (b) > mounting a filesystem, thus connecting it to the kernel's filesystem-system > -- a highly flammable area --, which practically assumes that the instance > is well-formatted, and demands exclusive write access. > I agree. makefs is what's usually used since it lets you layer in a tree as well. newfs on a file, by itself, isn't so useful, so this has remained broken... Warner From owner-freebsd-fs@freebsd.org Fri Jun 5 15:06:23 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A706732E149; Fri, 5 Jun 2020 15:06:23 +0000 (UTC) (envelope-from daspel@scinexus.com) Received: from mail.scinexus.com (mail.scinexus.net [45.56.106.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49dmFB39fpz43St; Fri, 5 Jun 2020 15:06:22 +0000 (UTC) (envelope-from daspel@scinexus.com) Received: from _ (localhost [127.0.0.1]) by mail.scinexus.com (Postfix) with ESMTPSA id 49dmF35dh6z5mRW; Fri, 5 Jun 2020 15:06:15 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Jun 2020 10:06:15 -0500 From: "R. Dominic Aspel" To: Nazim Can Bedir Cc: freebsd-fs@freebsd.org, owner-freebsd-fs@freebsd.org Subject: Re: newfs(1) on a file Organization: The SciNexus Reply-To: daspel@scinexus.com Mail-Reply-To: daspel@scinexus.com In-Reply-To: <1e6f811b-768b-0382-ff7e-54f0128cb876@protonmail.com> References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> <1e6f811b-768b-0382-ff7e-54f0128cb876@protonmail.com> Message-ID: <418bf09fe9715e9e99591c585b6871d5@scinexus.com> X-Sender: daspel@scinexus.com User-Agent: Roundcube Webmail X-Rspamd-Queue-Id: 49dmFB39fpz43St X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of daspel@scinexus.com has no SPF policy when checking 45.56.106.67) smtp.mailfrom=daspel@scinexus.com X-Spamd-Result: default: False [1.39 / 15.00]; HAS_REPLYTO(0.00)[daspel@scinexus.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; ARC_NA(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[scinexus.com]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_MEDIUM(0.11)[0.109]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.05)[-0.047]; NEURAL_SPAM_LONG(0.42)[0.416]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:63949, ipnet:45.56.96.0/20, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 15:06:23 -0000 I really miss the days when users were online to help users. Before all of these foul-mouthed, arrogant XBox babies came online to beat down users who only want to ask question and learn. Someday the Internet will purge these simple little boys and we can all get back to work. On 2020-06-04 16:20, Nazim Can Bedir via freebsd-fs wrote: > Linux is able to perform `swapon ./file`, FreeBSD isn't. > > Then, go fuck and use Linux. No body gives a shit about you and your > fucking preferred system. And, stay with Linux: asshole! -- --- It doesn't matter where I go, I'm not there anyway. From owner-freebsd-fs@freebsd.org Fri Jun 5 17:28:01 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CCC00331FA4 for ; Fri, 5 Jun 2020 17:28:01 +0000 (UTC) (envelope-from large.hadron.collider@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dqNc4wkTz4MBZ for ; Fri, 5 Jun 2020 17:28:00 +0000 (UTC) (envelope-from large.hadron.collider@gmx.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1591378078; bh=JhpMXDzZi/7Xzyjo/0djaD/4YRCAvhk5VzYqxMEXEik=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References; b=Wwrou2+9m/7FQHiQFJec9SRzc8WQUkIGsJMDQxNhkXFftRrGXwMFSqydA8arzz5H6 BOUsNxRW9pt8ORRpgJZn0/z9SUw+YxGToQlrggJDbH1Y19wIq2GTJkSmk5i/AzJPpY jQkgLBq+g5KlxbGsLGGSIEY3LBER5GWj1j613fuE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from Regeneratus.BC.CA.Umbrellix.NET ([50.69.229.17]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1McY8d-1j77230jzJ-00cvOs for ; Fri, 05 Jun 2020 19:27:58 +0200 Date: Fri, 5 Jun 2020 10:27:54 -0700 From: Large Hadron Collider To: freebsd-fs@freebsd.org Subject: Re: newfs(1) on a file Message-Id: <20200605102754.fbcca0f52fc6f7d19f85fe8d@gmx.com> In-Reply-To: <418bf09fe9715e9e99591c585b6871d5@scinexus.com> References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> <1e6f811b-768b-0382-ff7e-54f0128cb876@protonmail.com> <418bf09fe9715e9e99591c585b6871d5@scinexus.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:UuHlPAg6aEVmhC3njkZ24oetTDEMO894jiEKMtYhjCeVta4rRK0 DWrVAbMhB07ZhYO/S/mIew4pYGE5lYzQXujoC9c+MoSM5BUS+vvJc7z4P8uUasdpB1KjLU3 5Ezj+I+fHt8/uIiEIPAJfXbZNCJgJMh62Q+xuZakF0aib11kMXMF9GQYMNKOeikKK6++P18 o3AgfSG/wBoi2z9gW6Zng== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:wABBfU44c+Y=:CTXzxLMBg9XwBsXFTO0uN9 p1IFOpKSGnG7ANqlO0bWCcpLxUVfiUrM3UsjfqF0ksyG4tqJPgcZqMgYxGo465eutrmxASwVc KS7FS2f4RiAmlBGkKFXgZGWAO0fyXoBVq3qHJ6dAUkoNxRb7kz2cMAwIhbR9fqZ8RJV2zFWK6 DJKqpuZmunGbnpFm7Ta6PEU/KlIsYReASh51YTSL43DvbCiu/WWg76nB6xVuDe6Q0dSPpQ009 k/htTOGbMXn4DMZvNFSLW9oZK+JfLdCtmV67ujKZoI6kT2sJIjZm0NjlYAhv9v5FXWWSnyjD3 bj9pCPU7c9cMW10MBZsWwX5T4Y6FfAIzTBhmSF5zYCIQSdXBgUNjQnUCXTMimc1w3Nxw/Tit6 kT7ImEUnkiLaEOsfjH1o/e7L6zWpwZDRJr1EP7vrQZ2ibidu7w8l8cTr1QQk2KtZrG6TCV/By OgFwhJDh2RDobKvym/3dMBTmwN5yo99o/X6+CP1MCMChhirvsUHxKPE2kidbzrXIAvsFWZ07a yLhzDEAQ9v+ZcgjdUDbNu2PCrIhBTCBjROo6bU6GEqysZHIZ53qyb485i84wpoB8wymhI2MEB wHi3qJAQ3ghlHOgtnTqhByYKKGHXkGOPAYdw5PYWb09q8PbhGp/7M+gCyxsfEtrxkQz8voS2P GaaNawN/tP9nXMhP1qOCRt0yeIWlpy5t/eNqr1X79b7jZWGsKqkUcFpZYOlLSpse0nkyeO+kR ucmb+o64MoRcY1/vdVfcWPdPPqWZHYVXGf7MnvwA9O2ONtjVliV61InKPnOECsYVEkxZIOs1V bNOxQsyaPVCrwjGbialmKztAarcjvSvB9EqhifRFnFGwTKIHCu3QV9qJgOzAJrcODxPJN0i2P 30NEgJN+IBPmvip00rXPosOyPmvMkpR6urfbXY1Kvy4qmKYvt879ZpHd+lf2SUSxsAfM40hfU 8F105MIkwhkV8yyADCW4sWPKqiZDQEPh1gpZ9Qp9C0jsDGHbTJYwKJ67praG7S0W7JH7P72I9 Y0U5DmUBr4hkrIx/rgiiA77e/iaisyiMp2IVo+XPKpqsku8s1Y6oYXQqYnW4xBE5djHjd2Ztw RtwTKoGS7gFqOwxaC4XCTwwlFdqnpRBJu+icJtEgtFCcE8gJw0Ottkv+Kk1mYf/V9246xFiQo tM/SP58Eajg+mNvcLEFIpuVtO2QRk9dYLUKFU0D/WzCXNp0Da8VMBwmCc5OWQ9ciLjReirAzd CJx/JvW2eZJrCmfKy39VSpSifIZM4tdO5QXgycg== X-Rspamd-Queue-Id: 49dqNc4wkTz4MBZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=Wwrou2+9; dmarc=none; spf=pass (mx1.freebsd.org: domain of large.hadron.collider@gmx.com designates 212.227.15.15 as permitted sender) smtp.mailfrom=large.hadron.collider@gmx.com X-Spamd-Result: default: False [-2.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmx.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/24]; DKIM_TRACE(0.00)[gmx.net:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.com]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.15:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.972]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[gmx.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.01)[0.011]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.15:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 17:28:01 -0000 I find it unlikely. On Fri, 05 Jun 2020 10:06:15 -0500 "R. Dominic Aspel" wrote: > > > I really miss the days when users were online to help users. Before all > of these foul-mouthed, arrogant XBox babies came online to beat down > users who only want to ask question and learn. Someday the Internet > will purge these simple little boys and we can all get back to work. > > > > On 2020-06-04 16:20, Nazim Can Bedir via freebsd-fs wrote: > > Linux is able to perform `swapon ./file`, FreeBSD isn't. > > > > Then, go fuck and use Linux. No body gives a shit about you and your > > fucking preferred system. And, stay with Linux: asshole! > > -- > --- It doesn't matter where I go, I'm not there anyway. > _______________________________________________ > 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" =2D- Large Hadron Collider From owner-freebsd-fs@freebsd.org Fri Jun 5 20:28:42 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B614033712E; Fri, 5 Jun 2020 20:28:42 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dvP60Cj3z3XZT; Fri, 5 Jun 2020 20:28:41 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by mail-il1-x141.google.com with SMTP id g3so10866863ilq.10; Fri, 05 Jun 2020 13:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqKIHXZsVwncobCVP7v0aWUuTaOcVzSXdonRlrOwyjM=; b=q2Q3jnf+QMoT3eyoATxKnCPMxYFpQabanz0Dzk2keliGeJnAWzuVbOPSaMBn7IXE/G wzoL6GXHPNm8jayrAj3oLFBP4mabReMDSGaqQNTMDz9dwKUK3XwdrYu49Uilk61/gjNd dNwytL2mop5YVLEa1XxqlxBxsMlQDUa9z3lBMNXT05HwV6fQZbFKauv48geFtrxqLAZt sGJYadXESWne71VwIZC3BFt9oEFFdaI8aymZey0t4XTCB9FvxFR65mqa3jt/zP0eRm7b Agf4mQxu0zpEJcfzG9LJdaZKK4sXT5hsrhId3YQfMnV7pCr1gx/Cd328bL4RaV9jvj0O md5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqKIHXZsVwncobCVP7v0aWUuTaOcVzSXdonRlrOwyjM=; b=oFCUX//2LnmJrUMxJT0ATsU+2e84C557D3XQCapKfqEF5/dqer9llPDJ0FgbPcHBlo 3VlZIzBAxjDb3S5UfuTerPHCVUY1vDdPSjkQOhNh0m45xBGl9fhCSzsyKImTpndkkTAy meRW01iKHNS1GEM5hAGYPqh0DR3tQq5zpA3qX6YmsCHWugsiHT/e3OBdoSwqtYuRK6MI QLAd3EWTJxf8kIpO7AKtH/GwjGUYkTRresfXPYHz3iyUF1ZduHvyBhNgLd5YQWTFpjuA bjkWsh0UGt5+wotHsE7orpmWXGGxeo9WCiUz1AwggeExldo2TT1W7+Ehi5I08bLzyCr0 TYcQ== X-Gm-Message-State: AOAM5314la/TdKti515u+NXMpWxn8iT2U23AI4GE1GBOkV5sg+BTf+kU LxYdyvKploIAUCLPY2ZjUkYlul2ZomZNtKQYxbs= X-Google-Smtp-Source: ABdhPJyOM9IFBxL2leSZV9Xw2yOafAnmgQGHafuKdlFsCYCo8GR1ZCluDyuIk66Y+sAM5FUWtLwLPLsFjyOxhMoMY/8= X-Received: by 2002:a05:6e02:eb0:: with SMTP id u16mr10535387ilj.81.1591388921009; Fri, 05 Jun 2020 13:28:41 -0700 (PDT) MIME-Version: 1.0 References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> <1e6f811b-768b-0382-ff7e-54f0128cb876@protonmail.com> <418bf09fe9715e9e99591c585b6871d5@scinexus.com> In-Reply-To: <418bf09fe9715e9e99591c585b6871d5@scinexus.com> From: Aryeh Friedman Date: Fri, 5 Jun 2020 16:28:29 -0400 Message-ID: Subject: Re: newfs(1) on a file To: daspel@scinexus.com Cc: Nazim Can Bedir , freebsd-fs@freebsd.org, owner-freebsd-fs@freebsd.org X-Rspamd-Queue-Id: 49dvP60Cj3z3XZT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=q2Q3jnf+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of aryehfriedman@gmail.com designates 2607:f8b0:4864:20::141 as permitted sender) smtp.mailfrom=aryehfriedman@gmail.com X-Spamd-Result: default: False [-4.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.009]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.001]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::141:from]; NEURAL_HAM_SHORT(-1.57)[-1.572]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 20:28:42 -0000 On Fri, Jun 5, 2020 at 11:06 AM R. Dominic Aspel wrote: > > > I really miss the days when users were online to help users. Before all > of these foul-mouthed, arrogant XBox babies came online to beat down > users who only want to ask question and learn. Someday the Internet > will purge these simple little boys and we can all get back to work. > What you missed was the original question was being asked in the rudists possible way on purpose and likely was not even an honest question but an attempt to restart the OS wars. > > > > On 2020-06-04 16:20, Nazim Can Bedir via freebsd-fs wrote: > > Linux is able to perform `swapon ./file`, FreeBSD isn't. > > > > Then, go fuck and use Linux. No body gives a shit about you and your > > fucking preferred system. And, stay with Linux: asshole! > > -- > --- It doesn't matter where I go, I'm not there anyway. > _______________________________________________ > 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" > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-fs@freebsd.org Fri Jun 5 20:57:20 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0E9A3378BB for ; Fri, 5 Jun 2020 20:57:20 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 49dw275PVvz3Zxl for ; Fri, 5 Jun 2020 20:57:19 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jhJOu-00021U-7p; Fri, 05 Jun 2020 22:57:16 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "freebsd-fs@freebsd.org" , "Miroslav Lachman" <000.fbsd@quip.cz> Subject: Re: ZFS on FreeBSD 11.3 slower than 10.4 References: <1ff455a5-d111-86fa-ceb1-1021b6d9a5b6@quip.cz> <8c64cc48-7d79-7591-8bb5-67f3127463b7@quip.cz> Date: Fri, 05 Jun 2020 22:57:15 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <8c64cc48-7d79-7591-8bb5-67f3127463b7@quip.cz> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.2 X-Scan-Signature: ee739817b6cd2655ac6326818c89325b X-Rspamd-Queue-Id: 49dw275PVvz3Zxl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-2.46 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[195.190.28.88:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; NEURAL_HAM_LONG(-1.00)[-1.003]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[klop.ws]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.64)[-0.636]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 20:57:20 -0000 On Sat, 30 May 2020 23:29:48 +0200, Miroslav Lachman <000.fbsd@quip.cz> wrote: > On 2020-05-30 22:10, Ronald Klop wrote: >> On Sat, 23 May 2020 21:44:03 +0200, Miroslav Lachman <000.fbsd@quip.cz> >> wrote: >> >>> I upgraded my old desktop computer few month ago from old 10.4 based >>> PC-BSD to stock FreeBSD 11.3. It uses single 2TB HDD 7200rpm. >>> My problem is that upgraded version is really slow and some desktop >>> applications are very lagging (playing multimedia is interrupted for a >>> fraction of seconds) when there is heavy filesystem activity. >>> >>> I am using zfsnap2 for taking snapshots periodically and when there is >>> enough snapshots zfs destroy is called. In this time the user >>> experience is terrible. Starting new application like browser or even >>> something much smaller takes minutes. The old version based on FreeBSD >>> 10.4 behaves much better. I used the old version for years and never >>> have problems with interrupted multimedia playback. >>> >>> Are there some sysctls to tune to get better desktop interactivity in >>> heavy filesystem operations like zfs destroy, pkg check or other >>> "find" periodic scripts? > > >> How full is the disk? ZFS has poor performance if the disk becomes full. >> What is in /etc/sysctl.conf and /boot/loader.conf? >> And did you try to boot 12.1 and did it have the same behavious? > > It is currently 77% full. But it is the same pool with the same capacity > as with 10.4. > > I didn't try 12.1, I need to stay on 11.3 for now. > > ## loader.conf > > nvidia_load="YES" > drm_load="YES" > drm2_load="YES" > iicbus_load="YES" > vboxdrv_load="YES" > crypto_load="YES" > aesni_load="YES" > geom_eli_load="YES" > vfs.zfs.arc_max="1024M" > zfs_load="YES" > iicbus_load="YES" > > ## sysctl.conf > > kern.coredump=0 > kern.maxfiles=49312 > vfs.usermount=1 > security.jail.allow_raw_sockets=1 > security.jail.sysvipc_allowed=1 > security.jail.mount_allowed=1 > security.jail.chflags_allowed=1 > hw.syscons.bell=0 > kern.sched.preempt_thresh=224 > kern.ipc.shm_allow_removed=1 > kern.shutdown.poweroff_delay=500 > kern.bootfile=/boot/kernel/kernel > hw.usb.no_shutdown_wait=1 > hw.snd.default_unit=3 > kern.sched.interact=10 > vfs.aio.max_aio_per_proc=256 > vfs.aio.max_aio_queue=8192 > vfs.aio.max_aio_queue_per_proc=1024 > vfs.aio.max_buf_aio=64 > net.local.stream.recvspace=65536 > net.local.stream.sendspace=65536 > > > loader.conf and sysctl.conf are the same for 10.4 and 11.3 but 11.3 is > much much slower when it comes to heavy IO like "find" daily periodic > scripts, zfs destroy, starting new applications etc. > > > Kind regards > Miroslav Lachman I don't have anything I see which I'm sure will fix things, but you could try to remove/comment some of these sysctls to see if 11.3 has better defaults now. kern.sched.preempt_thresh, kern.maxfiles, kern.sched.interact, vfs.aio.* What kind of machine is it? CPU, MEM? What does gstat say about the saturation of the disk? Regards, Ronald. From owner-freebsd-fs@freebsd.org Fri Jun 5 21:26:32 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CF343382AA for ; Fri, 5 Jun 2020 21:26:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [IPv6:2607:f3e0:0:3::19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dwgq2DCbz3dr2 for ; Fri, 5 Jun 2020 21:26:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:c119:7ad8:e8da:5f8f] ([IPv6:2607:f3e0:0:4:c119:7ad8:e8da:5f8f]) by pyroxene2a.sentex.ca (8.15.2/8.15.2) with ESMTPS id 055LQUC3014889 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 5 Jun 2020 17:26:30 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: ZFS on FreeBSD 11.3 slower than 10.4 To: Miroslav Lachman <000.fbsd@quip.cz>, "freebsd-fs@freebsd.org" References: <1ff455a5-d111-86fa-ceb1-1021b6d9a5b6@quip.cz> From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= mQENBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAG0HW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+iQFUBBMBCAA+FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAlywzOYCGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ eVOEFl5WrMhnPAf7Bf+ola0V9t4i8rwCMGvzkssGaxY/5zNSZO9BgSgfN0WzgmBEOy/3R4km Yn5KH94NltJYAAE5hqkFmAwK6psOqAR9cxHrRfU+gV2KO8pCDc6K/htkQcd/mclJYpCHp6Eq EVJOiAxcNaYuHZkeMdXDuvvI5Rk82VHk84BGgxIqIrhLlkguoPbXOOa+8c/Mpb1sRAGZEOuX EzKNC49+GS9gKW6ISbanyPsGEcFyP7GKMzcHBPf3cPrewZQZ6gBoNscasL6IJeAQDqzQAxbU GjO0qBSMRgnLXK7+DJlxrYdHGXqNbV6AYsmHJ6c2WWWiuRviFBqXinlgJ2FnYebZPAfWiQ== Message-ID: <4c099bfc-1770-36be-2a17-d3be5cd00045@sentex.net> Date: Fri, 5 Jun 2020 17:26:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1ff455a5-d111-86fa-ceb1-1021b6d9a5b6@quip.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 49dwgq2DCbz3dr2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::19 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-1.15 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; NEURAL_HAM_LONG(-1.01)[-1.009]; MIME_GOOD(-0.10)[text/plain]; HFILTER_HELO_IP_A(1.00)[pyroxene2a.sentex.ca]; HFILTER_HELO_NORES_A_OR_MX(0.30)[pyroxene2a.sentex.ca]; DMARC_NA(0.00)[sentex.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.134]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.01)[-1.011]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 21:26:32 -0000 On 5/23/2020 3:44 PM, Miroslav Lachman wrote: > I upgraded my old desktop computer few month ago from old 10.4 based > PC-BSD to stock FreeBSD 11.3. It uses single 2TB HDD 7200rpm. > My problem is that upgraded version is really slow and some desktop > applications are very lagging (playing multimedia is interrupted for a > fraction of seconds) when there is heavy filesystem activity. > > Is it possible some of the Intel CPU mitigations are causing some of the slowdown ? They dont seem to be in 10x ? Maybe try disabling ? https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities     ---Mike From owner-freebsd-fs@freebsd.org Fri Jun 5 22:57:24 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D0FFE33A2C2 for ; Fri, 5 Jun 2020 22:57:24 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 49dyhg45Gpz45mY for ; Fri, 5 Jun 2020 22:57:23 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jhLH5-0000Jn-I3; Sat, 06 Jun 2020 00:57:21 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "freebsd-fs@freebsd.org" , "Miroslav Lachman" <000.fbsd@quip.cz>, "Ronald Klop" Subject: Re: ZFS on FreeBSD 11.3 slower than 10.4 References: <1ff455a5-d111-86fa-ceb1-1021b6d9a5b6@quip.cz> <8c64cc48-7d79-7591-8bb5-67f3127463b7@quip.cz> Date: Sat, 06 Jun 2020 00:57:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.2 X-Scan-Signature: 3c11394861542ed80f8a69179537bf2c X-Rspamd-Queue-Id: 49dyhg45Gpz45mY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-2.14 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[195.190.28.88:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[klop.ws]; NEURAL_HAM_LONG(-0.99)[-0.986]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.34)[-0.339]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_MEDIUM(-1.02)[-1.017]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 22:57:24 -0000 On Fri, 05 Jun 2020 22:57:15 +0200, Ronald Klop wrote: > On Sat, 30 May 2020 23:29:48 +0200, Miroslav Lachman <000.fbsd@quip.cz> > wrote: > >> On 2020-05-30 22:10, Ronald Klop wrote: >>> On Sat, 23 May 2020 21:44:03 +0200, Miroslav Lachman >>> <000.fbsd@quip.cz> wrote: >>> >>>> I upgraded my old desktop computer few month ago from old 10.4 based >>>> PC-BSD to stock FreeBSD 11.3. It uses single 2TB HDD 7200rpm. >>>> My problem is that upgraded version is really slow and some desktop >>>> applications are very lagging (playing multimedia is interrupted for >>>> a fraction of seconds) when there is heavy filesystem activity. >>>> >>>> I am using zfsnap2 for taking snapshots periodically and when there >>>> is enough snapshots zfs destroy is called. In this time the user >>>> experience is terrible. Starting new application like browser or even >>>> something much smaller takes minutes. The old version based on >>>> FreeBSD 10.4 behaves much better. I used the old version for years >>>> and never have problems with interrupted multimedia playback. >>>> >>>> Are there some sysctls to tune to get better desktop interactivity in >>>> heavy filesystem operations like zfs destroy, pkg check or other >>>> "find" periodic scripts? >> >> >>> How full is the disk? ZFS has poor performance if the disk becomes >>> full. >>> What is in /etc/sysctl.conf and /boot/loader.conf? >>> And did you try to boot 12.1 and did it have the same behavious? >> >> It is currently 77% full. But it is the same pool with the same >> capacity as with 10.4. >> >> I didn't try 12.1, I need to stay on 11.3 for now. >> >> ## loader.conf >> >> nvidia_load="YES" >> drm_load="YES" >> drm2_load="YES" >> iicbus_load="YES" >> vboxdrv_load="YES" >> crypto_load="YES" >> aesni_load="YES" >> geom_eli_load="YES" >> vfs.zfs.arc_max="1024M" >> zfs_load="YES" >> iicbus_load="YES" >> >> ## sysctl.conf >> >> kern.coredump=0 >> kern.maxfiles=49312 >> vfs.usermount=1 >> security.jail.allow_raw_sockets=1 >> security.jail.sysvipc_allowed=1 >> security.jail.mount_allowed=1 >> security.jail.chflags_allowed=1 >> hw.syscons.bell=0 >> kern.sched.preempt_thresh=224 >> kern.ipc.shm_allow_removed=1 >> kern.shutdown.poweroff_delay=500 >> kern.bootfile=/boot/kernel/kernel >> hw.usb.no_shutdown_wait=1 >> hw.snd.default_unit=3 >> kern.sched.interact=10 >> vfs.aio.max_aio_per_proc=256 >> vfs.aio.max_aio_queue=8192 >> vfs.aio.max_aio_queue_per_proc=1024 >> vfs.aio.max_buf_aio=64 >> net.local.stream.recvspace=65536 >> net.local.stream.sendspace=65536 >> >> >> loader.conf and sysctl.conf are the same for 10.4 and 11.3 but 11.3 is >> much much slower when it comes to heavy IO like "find" daily periodic >> scripts, zfs destroy, starting new applications etc. >> >> >> Kind regards >> Miroslav Lachman > > > I don't have anything I see which I'm sure will fix things, but you > could try to remove/comment some of these sysctls to see if 11.3 has > better defaults now. > kern.sched.preempt_thresh, kern.maxfiles, kern.sched.interact, vfs.aio.* > > What kind of machine is it? CPU, MEM? > What does gstat say about the saturation of the disk? > > Regards, > Ronald. What might also be interesting is which timer is selected. Sometimes for some reason another time-source is chosen which can influence a lot of things (like sound). Please post the output of "sysctl kern.eventtimer" and "sysctl kern.timecounter" if possible of 10.4 and 11.3. Or compare the /var/run/dmesg.boot files of 10.4 and 11.3 to see if some hardware is recognized differently. Regards, Ronald.