Date: Sun, 16 Jul 2023 18:17:09 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: rsync use with -tmsdosfs mounted file system? file has vanished: . . . Message-ID: <CAN6yY1vsUddvZcrUDrD_cMZL28to5MxDcNjfQNUrsxuCaUHiOw@mail.gmail.com> In-Reply-To: <485EB974-5EF4-4569-9B40-81A474983F33@yahoo.com> References: <485EB974-5EF4-4569-9B40-81A474983F33.ref@yahoo.com> <485EB974-5EF4-4569-9B40-81A474983F33@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 <http://yahoo.com>; 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. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">On Sun, Jul 16, 2023 at 1:57 PM Mark Millard <<a href="mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>> wrote:</div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I used a sequence that looked like:<br> <br> mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /CA72optM2efi-media/ \<br> && rsync -x --delete -aAUHhh --info=progress2 /boot/efi/ /CA72optM2efi-media/<br> <br> that got:<br> <br> file has vanished: "/CA72optM2efi-media/BCM271~5.DTB"<br> file has vanished: "/CA72optM2efi-media/BCM271~6.DTB"<br> 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]<br> <br> After that, activity reported the likes of:<br> <br> rsync: [generator] delete_file: unlink(overlays/VC4-KM~8.DTB) failed: Read-only file system (30)<br> and:<br> rsync: [receiver] mkstemp "/CA72optM2efi-media/.fixup4.dat.2Wonu9" failed: Read-only file system (30)<br> <br> More than rsync was odd at that point:<br> <br> # ls -Tld /CA72optM2efi-media/*.DTB<br> ls: /CA72optM2efi-media/BCM271~5.DTB: No such file or directory<br> ls: /CA72optM2efi-media/BCM271~6.DTB: No such file or directory<br> <br> # rm /CA72optM2efi-media/*/*.DTB<br> override rwxr-xr-x root/wheel uarch for /CA72optM2efi-media/overlays/SDHOST~1.DTB? y<br> rm: /CA72optM2efi-media/overlays/SDHOST~1.DTB: Read-only file system<br> . . .<br> <br> But:<br> <br> # mount | grep media<br> /dev/gpt/CA72optM2efi on /CA72optM2efi-media (msdosfs, local, noatime)<br> <br> So the mount itself was not the source of the read-only status so far.<br> <br> I then tried:<br> <br> # umount /CA72optM2efi-media<br> # newfs_msdos /dev/da0p1<br> # mount -onoatime -tmsdosfs /dev/gpt/CA72optM2efi /mnt<br> # cp -aRx /boot/efi/ /mnt/<br> cp: utimensat: /mnt: Invalid argument<br> <br> (which is normal).<br> <br> # umount /mnt<br> <br> No more oddities , so far after that.<br> <br> <br> For reference:<br> <br> # uname -apKU<br> 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<br> <br> # pkg info rsync<br> rsync-3.2.7<br> Name : rsync<br> Version : 3.2.7<br> Installed on : Sat Jul 15 14:53:48 2023 PDT<br> Origin : net/rsync<br> Architecture : FreeBSD:14:aarch64<br> . . .<br> Annotations :<br> FreeBSD_version: 1400092<br> build_timestamp: 2023-07-02T06:57:44+0000<br> built_by : poudriere-git-3.3.99.20220831<br> cpe : cpe:2.3:a:samba:rsync:3.2.7:::::freebsd14:aarch64<br> port_checkout_unclean: no<br> port_git_hash : f45cd5bd9d4b<br> ports_top_checkout_unclean: yes<br> ports_top_git_hash: 880f72e54deb<br> <br> <br> ===<br> Mark Millard<br> marklmi at <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.co</a></blockquote><div><br></div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">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.</div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">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. <br></div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif;font-size:small" class="gmail_default">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.<br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Kevin Oberman, Part time kid herder and retired Network Engineer<br>E-mail: <a href="mailto:rkoberman@gmail.com" target="_blank">rkoberman@gmail.com</a><br></div><div>PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683</div></div></div></div></div></div></div></div></div>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1vsUddvZcrUDrD_cMZL28to5MxDcNjfQNUrsxuCaUHiOw>