From owner-freebsd-fs@freebsd.org Fri Feb 12 16:22:48 2021 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 15E41528DF2 for ; Fri, 12 Feb 2021 16:22:48 +0000 (UTC) (envelope-from artem@artem.ru) Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (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 4Dcf1307mHz3K0q for ; Fri, 12 Feb 2021 16:22:46 +0000 (UTC) (envelope-from artem@artem.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail3; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=v1KJgSXf6A/9ImyHgP4D4Nth41zyi5nZZN/EyDMZyg8=; b=cds4VC/X0w4y/JHlK1pD8E71vNm5SEUCJEcd1na/QxF4OLm0DljAvqNQdQ9MdRplP1YgsxhTDs0afw2JGEvoBEdycKENIueSvA+0q/n7GQ7RcHqUPZ3QhlZr7iO5093sZvKzD63e5COm3peEXvxCB7xWzho95riwLkNLvM/b5Nw=; Received: by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1lAbDP-0003hT-5a for freebsd-fs@freebsd.org; Fri, 12 Feb 2021 19:22:43 +0300 Subject: Re: Reading a corrupted file on ZFS To: freebsd-fs@freebsd.org References: <0ca45adf-8f60-a4c3-6264-6122444a3ffd@denninger.net> <899c6b4f-2368-7ec2-4dfe-fa09fab35447@artem.ru> <20210212165216.2f613482@fabiankeil.de> From: Artem Kuchin Message-ID: <10977ffc-f806-69dd-0cef-d4fd4fc5f649@artem.ru> Date: Fri, 12 Feb 2021 19:22:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210212165216.2f613482@fabiankeil.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD981647AC6901E234BEAC4623CA173AF239537CEFAAFD1F814182A05F53808504028BF023574605706F5149E72AC5E6CF51BC03862E605979873832419281DFD85 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE788AD3E9728F968ABEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063748789019239639CB8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FCCAA1E616DB7D7B67006D1561EAE396976C271223FDCEE1E2389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0D9442B0B5983000E8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6E5E764EB5D94DBD4CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8D32BA5DBAC0009BE9E8FC8737B5C2249A6C381CD31D6A0BC76E601842F6C81A12EF20D2F80756B5F7E9C4E3C761E06A776E601842F6C81A127C277FBC8AE2E8B8412D6D77F9351F23AA81AA40904B5D9DBF02ECDB25306B2B25CBF701D1BE8734AD6D5ED66289B5278DA827A17800CE75A9E79F66F1C28F367F23339F89546C5A8DF7F3B2552694A6FED454B719173D6725E5C173C3A84C3335407143AA9223635872C767BF85DA2F004C906525384306FED454B719173D6462275124DF8B9C9D28595B116005B47574AF45C6390F7469DAA53EE0834AAEE X-B7AD71C0: 2623F767319EFA42AC98609FCEE262F9192335DD689A58EBAE0174B7F1092AFB6832F36CAB5E1658F54B3B24D578727D X-C1DE0DAB: 0D63561A33F958A5599F3654C47C35FFBC7C6DF768D09F90FA687722D79ACF35D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75B869F6C56E712840410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34F6CC1FD3366963368BCC3AE58132BD9C5EE804A7BD89E0B8C4A21DBCC66A862B6CE6BBB27F47B5A81D7E09C32AA3244C7D3B07382F924EEE51BF7F7C40BC6E8DE3D93501275E802F3EB3F6AD6EA9203E X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojtEL/kbq1PXHIc0MfyQ05bA== X-Mailru-Sender: 0E9E14D9EC491FBAA791EF7E2263ACA34AE573E1B9384DC1A8429F8B9C61AE32E38B3286BF0A6676ED68A1BC046237463DDE9B364B0DF2893588BD1191EC2D784A420497922026CACF2710667E7BD92C3CDA0F3B3F5B9367 X-Mras: Ok X-Rspamd-Queue-Id: 4Dcf1307mHz3K0q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mail.ru header.s=mail3 header.b=cds4VC/X; dmarc=none; spf=none (mx1.freebsd.org: domain of artem@artem.ru has no SPF policy when checking 94.100.177.92) smtp.mailfrom=artem@artem.ru X-Spamd-Result: default: False [-3.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[artem.ru]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.100.177.92:from:127.0.2.255]; DKIM_TRACE(0.00)[mail.ru:+]; NEURAL_HAM_SHORT(-0.98)[-0.985]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.100.177.92:from]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs]; RCVD_IN_DNSWL_LOW(-0.10)[94.100.177.92:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 16:22:48 -0000 12.02.2021 18:52, Fabian Keil пишет: > Artem Kuchin wrote on 2021-02-12: > >> 12.02.2021 18:06, Karl Denninger пишет: >>> Blocking the read forces you to get the good copy off backup media and >>> thus prevents that from happening. >>> >> I know what ZFS does and i damaged the same file in the same place on >> purpose. Question is: how to read what's left of it. Just for kicks, i >> don't have a backup, and i need to read what's left. It could be 1GB >> file with only one byte damaged and it is of crazy importance to me. So, >> how to bypass all the checks and make it read the file no matter what? > The patch from this PR adds a sysctl that allows to send corrupted data: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221909 > > Using the added sysctl you can send and receive the dataset and then > read the corrupted file from the received dataset. Note that ZFS replaces > corrupted blocks completely with the 0x'zfs badd bloc' pattern instead > of returning the corrupted data as is, thus increasing the amount of > corruption in case of simple bit flips to whole blocks. > > Fabian Arghh. That's not what i want. This is strange. In case of stupid old FS like FAT or even newer UFS i can dig into damaged file and collect as much data as possible, while newer ZFS does not provide tools to dig into data. That's was always my concern about ZFS. If something bad goes with FAT/NTFS and even UFS - there are tons of tools which can dissect the file system into bits so i can get as much as possible of what's left. In case of ZFS there are no tools that i know and even ZFS itself does not allow to get what left of normal data. This is frustrating. why..why..