Re: parent transid verify failed

[Eric Levy <contact@ericlevy.name>]

On Sat, 2022-01-01 at 22:27 -0500, Zygo Blaxell wrote:

> Yes, that's normal with lazy umounts.  With a lazy umount, the mount
> point is removed immediately, so you get all the behavior you
> described,
> but the filesystem is not actually umounted until after the last open
> file descriptors referencing the filesystem are closed (that's the
> "lazy" part).

All of the explicit umount calls I gave had no lazy flag. I don't
understand the full details of your comments, as I am only aware of
lazy umount as a fallback for failing umount calls in synchronous
operations.

It seems the way mounts work, especially when interacting with user
space solutions, such as FUSE and Gvfs, is often burdened by legacy
design never updated to work properly. I have seen Gvfs pull down an
entire system from trying to access a file in a user mount, since the
mount was made before a network connection with the Samba server was
dropped.

For laptops these kinds of vulnerability are quite debilitating.

> You can run btrfs scrub to verify the data and metadata.
> 
> The most probable outcome is that everything's OK.  The device layer
> reported failed writes to btrfs, and btrfs aborted the last
> transaction
> to protect the on-disk data.  I would not expect any errors in either
> btrfs check or scrub, as this scenario is one the filesystem is
> designed
> and tested for.

Great, thanks. Scrub reported no errors, and the check reported none,
as already mentioned.

> Since you're transitioning from one disk to multiple disks, you
> should
> convert metadata to raid1, and ensure there's sufficient unallocated
> space on the first drive to hold metadata as it grows.  This can be
> done

I thought it was the default for disk pools, fully duplicated metadata,
and JBOD-style for payload data.

> with two balance commands:
> 
> 	btrfs balance start -dlimit=16 /fs
> 
> 	btrfs balance start -mconvert=raid1,soft /fs

Does balance manage balanced utilization of disks? For specific
scenarios, unbalanced disk usage is actually desirable, for example, my
current one, in which the devices are logical volumes on a redundant
back end. Using as much of one volume as possible simplifies
reallocation of back end storage resources.

---

I am noticing that the order of devices in now reversed. I am wondering
whether what happened is that iSCSI, either on the client or server
side, reversed the order, by some quirk or design flaw. while I had the
live mount. Still, it doesn't explain why I originally was able to see
the new, unpartitioned device and add it to the pool.

Another possibility is that the sequence of add/remove/add, which I
explained earlier, caused some problem, but it also seems not clear
how, since all of these operations are synchronous.