From: Eric Levy <contact@ericlevy.name>
To: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: parent transid verify failed
Date: Sat, 01 Jan 2022 19:55:57 -0500 [thread overview]
Message-ID: <109cc618254b1f8d9365bd4ecb7eb435dea91353.camel@ericlevy.name> (raw)
In-Reply-To: <YdDurReZpZQeo+7/@hungrycats.org>
On Sat, 2022-01-01 at 19:15 -0500, Zygo Blaxell wrote:
> Try rebooting to make sure the old mount is truly gone.
>
> If the filesystem has been lazily umounted with open files it can be
> very difficult to find all the processes that are still holding the
> files open and force them to close. Tools like 'fuser' and 'lsof'
> don't work after all the mount points have been deleted.
I couldn't find any indication that the file system remained mounted.
The mount point was empty, umount commands failed for all target
devices, as well as the mount point, and the mount table showed no
relevant entries.
I rebooted, and the file system mounted automatically (as normal). I
found no reports of problems in the log (below).
I performed a trivial test (writing "Hello world" to a file, and
reading), and it performed correctly.
Is it likely that data written before the bad events is entirely
intact, that all parts of the file tree not touched afterward have not
been damaged? How confident should I be of not having corruption?
Is it safe to try to continue to write data beyond the capacity of the
first device, into the additional device?
---
Jan 01 19:26:43 hostname kernel: Loading iSCSI transport class v2.0-870.
Jan 01 19:26:43 hostname kernel: iscsi: registered transport (tcp)
Jan 01 19:26:43 hostname kernel: aufs 5.x-rcN-20210809
Jan 01 19:26:43 hostname kernel: scsi host4: iSCSI Initiator over TCP/IP
Jan 01 19:26:43 hostname kernel: scsi host5: iSCSI Initiator over TCP/IP
Jan 01 19:26:43 hostname kernel: scsi 4:0:0:2: Direct-Access SYNOLOGY Storage 4.0 PQ: 0 ANSI: 5
Jan 01 19:26:43 hostname kernel: sd 4:0:0:2: Attached scsi generic sg4 type 0
Jan 01 19:26:43 hostname kernel: sd 4:0:0:2: [sdc] 524288000 512-byte logical blocks: (268 GB/250 GiB)
Jan 01 19:26:43 hostname kernel: sd 4:0:0:2: [sdc] Write Protect is off
Jan 01 19:26:43 hostname kernel: sd 4:0:0:2: [sdc] Mode Sense: 43 00 10 08
Jan 01 19:26:43 hostname kernel: sd 4:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
Jan 01 19:26:43 hostname kernel: sd 4:0:0:2: [sdc] Optimal transfer size 16384 logical blocks > dev_max (8192 logical blocks)
Jan 01 19:26:43 hostname kernel: scsi 4:0:0:1: Direct-Access SYNOLOGY iSCSI Storage 4.0 PQ: 0 ANSI: 5
Jan 01 19:26:43 hostname kernel: sd 4:0:0:1: Attached scsi generic sg5 type 0
Jan 01 19:26:43 hostname kernel: sd 4:0:0:1: [sdd] 524288000 512-byte logical blocks: (268 GB/250 GiB)
Jan 01 19:26:43 hostname kernel: sd 4:0:0:1: [sdd] Write Protect is off
Jan 01 19:26:43 hostname kernel: sd 4:0:0:1: [sdd] Mode Sense: 43 00 10 08
Jan 01 19:26:43 hostname kernel: sd 4:0:0:1: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA
Jan 01 19:26:43 hostname kernel: sd 4:0:0:1: [sdd] Optimal transfer size 16384 logical blocks > dev_max (8192 logical blocks)
Jan 01 19:26:43 hostname kernel: sdd: sdd1
Jan 01 19:26:43 hostname kernel: sd 4:0:0:2: [sdc] Attached SCSI disk
Jan 01 19:26:43 hostname kernel: sd 4:0:0:1: [sdd] Attached SCSI disk
Jan 01 19:26:43 hostname kernel: BTRFS: device fsid c6f83d24-1ac3-4417-bdd9-6249c899604d devid 2 transid 9211 /dev/sdc scanned by systemd-udevd (386)
Jan 01 19:26:44 hostname kernel: BTRFS: device fsid c6f83d24-1ac3-4417-bdd9-6249c899604d devid 1 transid 9211 /dev/sdd1 scanned by systemd-udevd (396)
Jan 01 19:26:44 hostname kernel: kauditd_printk_skb: 13 callbacks suppressed
Jan 01 19:26:44 hostname kernel: audit: type=1400 audit(1641083204.403:25): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=670 comm="cups-browsed" capability=23 capname="sys_nice"
Jan 01 19:26:47 hostname kernel: audit: type=1400 audit(1641083207.587:26): apparmor="STATUS" operation="profile_load" profile="unconfined" name="docker-default" pid=993 comm="apparmor_parser"
Jan 01 19:26:49 hostname kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
Jan 01 19:26:49 hostname kernel: Bridge firewalling registered
Jan 01 19:26:49 hostname kernel: bpfilter: Loaded bpfilter_umh pid 1017
Jan 01 19:26:49 hostname unknown: Started bpfilter
Jan 01 19:26:50 hostname kernel: Initializing XFRM netlink socket
Jan 01 19:28:45 hostname kernel: BTRFS info (device sdd1): flagging fs with big metadata feature
Jan 01 19:28:45 hostname kernel: BTRFS info (device sdd1): disk space caching is enabled
Jan 01 19:28:45 hostname kernel: BTRFS info (device sdd1): has skinny extents
Jan 01 19:28:45 hostname kernel: FS-Cache: Loaded
Jan 01 19:28:45 hostname kernel: FS-Cache: Netfs 'nfs' registered for caching
Jan 01 19:28:45 hostname kernel: NFS: Registering the id_resolver key type
Jan 01 19:28:45 hostname kernel: Key type id_resolver registered
Jan 01 19:28:45 hostname kernel: Key type id_legacy registered
Jan 01 19:28:45 hostname kernel: FS-Cache: Duplicate cookie detected
Jan 01 19:28:45 hostname kernel: FS-Cache: O-cookie c=00000000eab55a10 [p=00000000197b94cc fl=222 nc=0 na=1]
Jan 01 19:28:45 hostname kernel: FS-Cache: O-cookie d=000000007bc6e6c7 n=00000000d6efde4c
Jan 01 19:28:45 hostname kernel: FS-Cache: O-key=[16] '0400000001000000020008010a040102'
Jan 01 19:28:45 hostname kernel: FS-Cache: N-cookie c=00000000d8681119 [p=00000000197b94cc fl=2 nc=0 na=1]
Jan 01 19:28:45 hostname kernel: FS-Cache: N-cookie d=000000007bc6e6c7 n=00000000fd46ace5
Jan 01 19:28:45 hostname kernel: FS-Cache: N-key=[16] '0400000001000000020008010a040102'
Jan 01 19:29:15 hostname kernel: BTRFS info (device sdd1): the free space cache file (274908315648) is invalid, skip it
next prev parent reply other threads:[~2022-01-02 0:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 21:10 parent transid verify failed Eric Levy
2021-12-30 21:47 ` Chris Murphy
2022-01-01 15:11 ` devel
2021-12-31 19:14 ` Zygo Blaxell
2021-12-31 20:33 ` Eric Levy
2021-12-31 23:09 ` Chris Murphy
2022-01-01 7:33 ` Eric Levy
2022-01-01 20:49 ` Chris Murphy
2022-01-01 21:57 ` Eric Levy
2022-01-01 20:56 ` Zygo Blaxell
2022-01-01 21:58 ` Eric Levy
2022-01-02 0:15 ` Zygo Blaxell
2022-01-02 0:55 ` Eric Levy [this message]
2022-01-02 3:27 ` Zygo Blaxell
2022-01-02 4:03 ` Eric Levy
2022-01-02 5:57 ` Zygo Blaxell
2022-01-02 10:17 ` Eric Levy
2022-01-03 7:41 ` Chris Murphy
2022-01-02 7:31 ` Andrei Borzenkov
-- strict thread matches above, loose matches on Subject: below --
2017-05-11 10:01 Massimo B.
[not found] <E18363B1-CD81-41F4-A03C-4D09AA669915@plack.net>
2015-04-28 12:34 ` Anthony Plack
2010-09-06 17:28 Jan Steffens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=109cc618254b1f8d9365bd4ecb7eb435dea91353.camel@ericlevy.name \
--to=contact@ericlevy.name \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).