From nobody Sat Apr 16 21:42:04 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E9529F7E834 for ; Sat, 16 Apr 2022 21:42:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kgmr81kx4z3m04 for ; Sat, 16 Apr 2022 21:42:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2d.google.com with SMTP id 190so3862529vse.8 for ; Sat, 16 Apr 2022 14:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=beENDYFEDXWoZwKvyPF1IUjYLra4iUj31+VaKqrMHcg=; b=yomFsdE3QBpH18t+R5gIOSYxfNEf2Rjbk1qswFSqoa+sSnosbIWhpQXeyhHl+br/pc EdkQb0AyLYrpPglnrNnYFQ9Y4Xo/KGk58mou/tXRyxbIQDQKOmG7BzmmLG08bM9pcQDf NRTcbNuf1pX/ByJ//sIr6npUOmfH9MDcNcBUvfXSsD3MkXGA7k4u9gHJAlfoYFg9frfM gqooVhbZ3xCdhs19sf23Xcx5hRq7zuD8T9pIOY5XyjlmS2uS6GcxZvnIzxtOjE5cu+JH oNchJ5JCAb1GH6Aqcmcu2jSdeWROaTbYi341dwzZ0QNh5UaAe5zuqq6cF6JWRbNBxJYs u5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=beENDYFEDXWoZwKvyPF1IUjYLra4iUj31+VaKqrMHcg=; b=UArgfjJsWxrYaOL5IuCFZWUSMtOBjxuAqVuKjvu2Z29eCqGJk+oB+1Z0yXvTd1RMGy 1tLjC9HQwUG3lnrbS/hkKQAfLfealL73b2DreLsKe27toxvyYak9t0HK5PphbGouRkf7 pUvWrzVDnGTNus0IF663aCnPMrJgit0qJqO/snwQkFRG8LpSkC+m5imjiJBtQ6bmkbBP wgdd4K64uvDbtDBdM4OOzIJIB5zUnZxwCOQ20b70u6n9wlbVPuEw4dFgDVJ7ar9VALUM YMBgddTQ1iZRljdM7Oeaj0uNxlHhyilzfdvVq4oo5/fKmgbu5e4Ral5WgsIYXaSf2u3B zE4g== X-Gm-Message-State: AOAM533iCk3eBNLTmNLzrmxzZeqI4/YNDtSFL9lk2oG+d8oH7ipT+SBj 1EcUX0QhjpE4xTQQ3/jZSgDblfrAf1q8zzWg7TVrpw== X-Google-Smtp-Source: ABdhPJxUFozU9FGmfoeobhOX2oMhXbWQhI0Gm4+RQH+cL/DU/NTSXK+/WJ0V+BkzKwkOGY2MYnf3gNF8XPVH5vcDeJk= X-Received: by 2002:a05:6102:38e:b0:32a:5175:b45d with SMTP id m14-20020a056102038e00b0032a5175b45dmr56774vsq.44.1650145335539; Sat, 16 Apr 2022 14:42:15 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 16 Apr 2022 15:42:04 -0600 Message-ID: Subject: Re: recover deleted file To: Sami Halabi Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000008d8bf305dccc661d" X-Rspamd-Queue-Id: 4Kgmr81kx4z3m04 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=yomFsdE3; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; 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] X-ThisMailContainsUnwantedMimeParts: N --0000000000008d8bf305dccc661d Content-Type: text/plain; charset="UTF-8" On Sat, Apr 16, 2022 at 5:24 AM Sami Halabi wrote: > Hi, > is there anyway easy to restore deleted file by accident in UFS???? > Do you know what the contents of the file is? At least the first, say, ~32k? The problem with unrm for ufs is that the directory entry has the inode number stored in it. Without the inode number, you won't get very far. With the inode number, you can get the first 12 filesystem blocks of the file and the first three indirect blocks. Once you have those, you can reconstruct the file. But only if the inode hasn't been zero'd out (which it likely has, another thing that makes UFS undelete harder). But all hope isn't lost... UFS has a predictable allocation algorithm that lets you get much of the file back (which is why I asked if you know how it should start: you can find where it starts in the data blocks and maybe get lucky with the rest if the data spills into indirect blocks). However, that's only if you don't have TRIM enabled on the filesystem. If you do, then UFS will do a BIO_DELETE of the blocks, which means their contents are likely gone at the drive level. I say likely because there's weasel words in the ATA spec that allows a drive to return the prior contents of the blocks, or all zeros or the drive's initialization pattern (usually all 1's) when the blocks are later read. Same goes for NVMe drives (with the additional constraint it must be deterministic). So there's may still be a chance you can read the old contents, but drives that do that are rare in my experience (which is admittedly quite narrow). But, if you want to use fsdb to try to recover this data, or write your own tools, then you should likely have a copy of the daemon book (The Design and Implementation of the FreeBSD Operating System). It explains a lot of the finer details of UFS and reference to it likely will catch me where my memory isn't quite right in the above descriptions. So, it's for all these reasons you can't find somebody with a unrm command for ufs like you can for DOS or other filesystems. I wish I had a better answer for you. Warner > Sami > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert > --0000000000008d8bf305dccc661d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Apr 16, 2022 at 5:24 AM Sami = Halabi <sodynet1@gmail.com>= wrote:
Hi,
is there anyway easy to restore deleted file by accident i= n UFS????

Do you know what the = contents of the file is? At least the first, say, ~32k?

The problem with unrm for ufs is that the directory entry has the ino= de number stored in it.
Without the inode number, you won't g= et very far.
With the inode number, you can get the first 12 file= system blocks of the file and the
first three indirect blocks. On= ce you have those, you can reconstruct the file.

B= ut only if the inode hasn't been zero'd out (which it likely has, a= nother thing that makes
UFS undelete harder). But all hope isn= 9;t lost...=C2=A0 UFS has a predictable allocation algorithm
that= lets you get much of the file back (which is why I asked if you know how i= t should start:
you can find where it starts in the data blocks a= nd maybe get lucky with the rest if the
data spills into indirect= blocks).

However, that's only if you don'= t have TRIM enabled on the filesystem. If you do,
then UFS will d= o a BIO_DELETE of the blocks, which means their contents are
like= ly gone at the drive level. I say likely because there's weasel words i= n the ATA
spec that allows a drive to return the prior contents o= f the blocks, or all zeros or
the drive's initialization patt= ern (usually all 1's) when the blocks are later read. Same
go= es for NVMe drives (with the additional constraint it must be deterministic= ). So there's
may still be a chance you can read the old cont= ents, but drives that do that are rare
in my experience (which is= admittedly quite narrow).

But, if you want to use= fsdb to try to recover this data, or write your own tools,
then = you should likely have a copy of the daemon book (The Design and Implementa= tion
of the FreeBSD Operating System). It explains a lot of the f= iner details of UFS and
reference to it likely will catch me wher= e my memory isn't quite right in the above
descriptions.

So, it's for all these reasons you can't find = somebody with a unrm command for ufs
like you can for DOS or othe= r filesystems. I wish I had a better answer for you.

Warner
=C2=A0
Sami

--
Sami Halabi
Infor= mation Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Asterisk Expert<= /div>
--0000000000008d8bf305dccc661d--