Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Jul 2023 20:46:30 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Kevin Oberman <rkoberman@gmail.com>
Cc:        Current FreeBSD <freebsd-current@freebsd.org>
Subject:   Re: rsync use with -tmsdosfs mounted file system? file has vanished: . . .
Message-ID:  <4B7DD1D6-00F8-436F-A107-2BFD970FAA01@yahoo.com>
In-Reply-To: <CAN6yY1vsUddvZcrUDrD_cMZL28to5MxDcNjfQNUrsxuCaUHiOw@mail.gmail.com>
References:  <485EB974-5EF4-4569-9B40-81A474983F33.ref@yahoo.com> <485EB974-5EF4-4569-9B40-81A474983F33@yahoo.com> <CAN6yY1vsUddvZcrUDrD_cMZL28to5MxDcNjfQNUrsxuCaUHiOw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 16, 2023, at 18:17, Kevin Oberman <rkoberman@gmail.com> wrote:

> On Sun, Jul 16, 2023 at 1:57=E2=80=AFPM Mark Millard =
<marklmi@yahoo.com> wrote:
>> I used a sequence that looked like:
>>=20
>> mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /CA72optM2efi-media/ =
\
>> && rsync -x --delete -aAUHhh --info=3Dprogress2 /boot/efi/ =
/CA72optM2efi-media/
>>=20
>> that got:
>>=20
>> file has vanished: "/CA72optM2efi-media/BCM271~5.DTB"
>> file has vanished: "/CA72optM2efi-media/BCM271~6.DTB"
>>          73.77K   0%    1.63MB/s    0:00:00 (xfr#7, to-chk=3D0/493)   =
rsync warning: some files vanished before they could be transferred =
(code 24) at main.c(1357) [sender=3D3.2.7]
>>=20
>> After that, activity reported the likes of:
>>=20
>> rsync: [generator] delete_file: unlink(overlays/VC4-KM~8.DTB) failed: =
Read-only file system (30)
>> and:
>> rsync: [receiver] mkstemp "/CA72optM2efi-media/.fixup4.dat.2Wonu9" =
failed: Read-only file system (30)
>>=20
>> More than rsync was odd at that point:
>>=20
>> # ls -Tld /CA72optM2efi-media/*.DTB
>> ls: /CA72optM2efi-media/BCM271~5.DTB: No such file or directory
>> ls: /CA72optM2efi-media/BCM271~6.DTB: No such file or directory
>>=20
>> # rm /CA72optM2efi-media/*/*.DTB
>> override rwxr-xr-x root/wheel uarch for =
/CA72optM2efi-media/overlays/SDHOST~1.DTB? y
>> rm: /CA72optM2efi-media/overlays/SDHOST~1.DTB: Read-only file system
>> . . .
>>=20
>> But:
>>=20
>> # mount | grep media
>> /dev/gpt/CA72optM2efi on /CA72optM2efi-media (msdosfs, local, =
noatime)
>>=20
>> So the mount itself was not the source of the read-only status so =
far.
>>=20
>> I then tried:
>>=20
>> # umount /CA72optM2efi-media
>> # newfs_msdos /dev/da0p1
>> # mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /mnt
>> # cp -aRx /boot/efi/ /mnt/
>> cp: utimensat: /mnt: Invalid argument
>>=20
>> (which is normal).
>>=20
>> # umount /mnt
>>=20
>> No more oddities , so far after that.
>>=20
>>=20
>> For reference:
>>=20
>> # uname -apKU
>> FreeBSD CA72-16Gp-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #99 =
main-n264171-2a0c0aea4209-dirty: Fri Jul 14 21:00:44 PDT 2023     =
root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400093 1400093
>>=20
>> # pkg info rsync
>> rsync-3.2.7
>> Name           : rsync
>> Version        : 3.2.7
>> Installed on   : Sat Jul 15 14:53:48 2023 PDT
>> Origin         : net/rsync
>> Architecture   : FreeBSD:14:aarch64
>> . . .
>> Annotations    :
>> FreeBSD_version: 1400092
>> build_timestamp: 2023-07-02T06:57:44+0000
>> built_by       : poudriere-git-3.3.99.20220831
>> cpe            : cpe:2.3:a:samba:rsync:3.2.7:::::freebsd14:aarch64
>> port_checkout_unclean: no
>> port_git_hash  : f45cd5bd9d4b
>> ports_top_checkout_unclean: yes
>> ports_top_git_hash: 880f72e54deb
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.co
>=20
> This looks a bit like an issue I was hitting on a 4 CPU, 4 thread =
Alder Lake processor and 500GB SSD running 13.2-RELEASE.
>=20
> I saw several very strange corruptions, at least one "rsync warning: =
some files vanished before they could be transferred". In one (the last) =
case, the system crashed. The 'disc' was corrupted badly enough that =
fsck failed and I could not boot up the system. The disk was UFS2 GPT =
format and EFI boot. The interface is SATA, not nVME. In this case, I =
was installing on a new system and copying the majority of the file =
system from my old system.=20
>=20
> The 'fix' is strange and probably not one many other can use. I =
installed a spinning rust drive of 500GB and installed FreeBSD and used =
rsync again and it worked. I can't say whether it was a fluke that it =
worked, but it really smells like some sort of race condition. Could be =
rsync , VFS, or device driver. Since then I have seen one crash while =
backing up the system disk using rsync. No corruption and doing another =
rsync after reboot worked fine, but it was a much smaller run as the =
first attempt was nearly complete when the system crashed. Maybe =
unrelated. I do have the core file from the crash. Stil, something weird =
has been going on. Same issue on two identical systems, so not likely =
hardware.

Adding background from my example, helping identify the variety of =
contexts that
sometimes the message:

The target drive was a 894 GiByte USB3 drive, of all things a Optane U2 =
used via a
USB3 adapter. GPT. Per the mount that I showed: msdosfs partition, the =
one that has
FreeBSD's UEFI loader copy that would be used in booting. (In my =
context, it also
gets RPi* related boot materials to allow booting RPi4B's, a RPi3B, and =
a RPi2B
v1.2. There are directories used as holding areas for alternate RPi* =
related
materials (versions), the holding area for the ready-to-use materials =
being empty
at the time: the mterials are out where they would be used.)

The booted world/kernel media was a PCIe Optane. Its msdosfs also has =
the RPi*
materials, despite the PCIe Optane not being bootable on an RPi* =
configuration
that I can form. These materials where what rsync was copying from. So =
the
rsync was between 2 msdosfs, not across file system types.

aarch64 with 16 Cortex-A72 's and 64 GiBytes of RAM.

main (so: 14).

So a fair number of things are not in common with your examples, which =
might at
least help limit the range of potential answers to: "what all is common =
to all
the failures?".


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B7DD1D6-00F8-436F-A107-2BFD970FAA01>