Re: rsync use with -tmsdosfs mounted file system? file has vanished: . . .
- In reply to: Kevin Oberman : "Re: rsync use with -tmsdosfs mounted file system? file has vanished: . . ."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 17 Jul 2023 03:46:30 UTC
On Jul 16, 2023, at 18:17, Kevin Oberman <rkoberman@gmail.com> wrote: > On Sun, Jul 16, 2023 at 1:57 PM Mark Millard <marklmi@yahoo.com> wrote: >> I used a sequence that looked like: >> >> mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /CA72optM2efi-media/ \ >> && rsync -x --delete -aAUHhh --info=progress2 /boot/efi/ /CA72optM2efi-media/ >> >> that got: >> >> 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=0/493) rsync warning: some files vanished before they could be transferred (code 24) at main.c(1357) [sender=3.2.7] >> >> After that, activity reported the likes of: >> >> 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) >> >> More than rsync was odd at that point: >> >> # 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 >> >> # 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 >> . . . >> >> But: >> >> # mount | grep media >> /dev/gpt/CA72optM2efi on /CA72optM2efi-media (msdosfs, local, noatime) >> >> So the mount itself was not the source of the read-only status so far. >> >> I then tried: >> >> # umount /CA72optM2efi-media >> # newfs_msdos /dev/da0p1 >> # mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /mnt >> # cp -aRx /boot/efi/ /mnt/ >> cp: utimensat: /mnt: Invalid argument >> >> (which is normal). >> >> # umount /mnt >> >> No more oddities , so far after that. >> >> >> For reference: >> >> # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400093 1400093 >> >> # 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 > > > === > Mark Millard > marklmi at yahoo.co > > 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. > > 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. > > 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?". === Mark Millard marklmi at yahoo.com