From nobody Mon Jul 17 03:46:30 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R47LG6lVyz4nP77 for ; Mon, 17 Jul 2023 03:46:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4R47LG49Byz3F0V for ; Mon, 17 Jul 2023 03:46:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689565604; bh=ptq24cP22eHXwP1Mlqpa4RSj8172v6slzcOpfXaKsQw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KhphRCSdM28Mtgp0n/4uE8PvB16HRedMC/8Gh1wm5hSF/bTOJC5mTG/eRc79c2k0Az5IB6qVaIwAUZhRVBvfJeH5qg9Ub3FY0AGz4qBEp9d8R771UKXMQFo3j3TaJ6p3nEH39VijHRxUH15+uPPA3b9FKxVL1ejTuJ8jRfSPj9r3ZOPDVtoI1hLXPmf2JvOMsh3s0YhLZUbcBvIQD2EL3TXQ6C+G0FKDPCO/dafOle/7eXqeroTR+VDPdh0fY4/utVxT8U4/Ixj1I5Cl9LNIXWBiqdlINCCRNb+sq5gVYEYLMrTLMB3a+jtHbUISL8CUfx+oi8wNtkaceBUn4fsBBg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689565604; bh=m2k6GKTx3zUh7m6h1ha6AJGFpqCuk4i9zJkcWvZi5ET=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oORSQIKD8PPKOGplWQ0BJFkcTg10bMEpYjcwY1HuhxY8lKxW6ir8FL/vAfn61VrU12VnPo9pv/ImHghGCGhvd3Lhgq+N5YZMOjAnigpF0RQmltTWoWtMv77C8hScIZuKaluQcSGuzM7ItwjhiLCqfL5Bd/ZhrD4qYBKoejAzx6VTGSLfJIVsV7PUGquByYKnCMGQQY/pBarK6nK37Lzr/TZ/QKn3zTC8jJggn9/Mgcq+c73J1xmNZu2qv8zCN7hPRYa9Z1Qq5y41oNi+Csl8MJzm3EAbQUlCDYslOFVTyY0Vdd6ajagRtUxF2qscAHQ9zpVWsq7BM4XsCB3F7rjISA== X-YMail-OSG: kRvf7LYVM1lDfwQbejqLIv7V2dRBqkK._k7FGgg3LzGMTOrZLjkMVxsgMfyM8vb sGbrXF7dqf7SJlOi8sWZauebHnTfu.wTX87dH4VYnY4ZHgUZSAMs9ymllMMIM1Jqxtqj2ivIqcjj slx0ba.6Pe2grEPuqKBquiLUIftynOx6r83x00jiA2wu3u90hdQCdkDgHHf2ya_XqQf7Fy9R0eSi I1DrggA_jaUBF1J34gT9u4l4ghBQHxFVujPXkqPpLWEXyx.2lFvlyVEKcB1pENdrrScHxVkVRiM6 vZAh7BLhcgfMzVG9olqlWRINyx8mIcEGHxr6b95us1CeuQ._oKoV2zccpl6QW.ymLe0D.XSR8IsB NekP5KahMJs6P2om0aVdHmuK3l9Xo8c0YwuagxILXKuzKN.a_m5Vk4qye3zbYWPQ9c59Jz4JAPFn jQztvNoXHLzPdfsA1Oonf_DpNdwjMPuRngevTurlRYfuumd7cR2j6MURzL1xe_hU_uXJGb_1Y.W9 5wqKsycDn5hJU.SrZ7ocqgssftGqiNc9bbL2yXvZBiEidlqPRNGUHa9hcoF3SjjRHSeBscZkiyMf RvYGwrMWjWf8vZpoGr18IPCN9t2w837cNaX2o6dGDCWGbW2tE9Qir5CXAz1y47uWpfF1QaIVGuGq OVgl_5CvbYRMBmpY8qZ4FeqBc_X7Y7Kfa0.d8sUmoehtvaN7iDS4g9bn0vgtlkff2U3YbQDsPCKn H14ndOkpLCtAM6t3_njj1mpU5pfSsk7VoFmWvXqUIEnGt4Y1yfmVpsgvFWEwIjjiSCbDGG9aV9Ij hZo84T0ePfKhlRq74o5khBpakH_1FTwY_zXI.kBf9GzvG4fyolBXc.P0tH6ckajLIPkBV.pDCqHz ONoOjgNdLWP9L..ruDlJg8XG1BV3x0rim6hdR5OZtqo4YL9L3KeLXc_6hivYA8kOEgB59ic.iVVv IQoN.JNXQiUnWgkPG68eRB5QdSSXcC5oSb2w4R4pnNd4ysIy0TsUofmsCWULD8O4o6NJodzxJDZc s7gG_0BkKTMO9eXtfSLo62k5ISLHjaB2cqCm1x2hu3fQdDPjBo5kFTC2q_rG4OSSBb0ZDvsb3yop p_4QVB7VVw5IXkifievQTk.Pks.9t4RoxiUxgrEAeDDJJz07Fb_yPaVbNoeBLZ5KHI1XVq0F0kY2 8RKTMNvxHESn6JnufG.F2ZhBF6sqHeDYDlBrjyczrSZMV0XChyjRtw.2oePmW9bzv.BZ.jte8jXO .qLZ772Iwi1QJxL__QL1j5LV81eolFFLSEMbxUlT_yDJy5LeSUlFzxo.Asp4qCXWVGRxGObkBE71 Y8MOxdYcBHzjuriVCUJiVjRmL2tcELVz4GD7SKkxNW3LYQpXQ0x2Qh7tI4iX7DjeUXZOtzH.BhDJ RgNvhx7oAg.w224MYxyFbUsr.5Q8a33cHHWJZccn4MppJA_GimiRkucDDep1IQ9ftIparDa1D1Kq uJav59Foj6VVKfY.yB_l_iM45PnJWvctrc7EH45ZYSwkK.BWZTyrCt3XqM7WVWPhPZH_hzVZDiBD g_Q1HgteJGAwKUEoixuQ6OGJFzemKdujkpnz9B9RNIaV6RlchSxxl1dydhoMIar08OMJR88HjcyR AaneqmJZ1gM4ZjY5.ohe86vJ5mdkua8m6VA.h5u454JRcjod7O7TUiFrDAN7vfRqycOZ_R6205aT zS4p8HLj.U_nH_.MAi.1LhhkEB9E8zNnB.cQKoOte0YI_9gWA_7jQ2cA0DfPtYrvRP22nP.qBjzU GGakfi6fmXztC4f19O.JInahMAjab4W1s6L8mCjVgWMgWfa_rbDV7tbiBxjJN60SnT45ceDA2U_4 XfMQLq4TkJf_a9nxryeT3glbb.NJfaMtOvEqqNo1x_xlnnM3PKBLgfTNikF7Hb64XjZBtrak54zz vyUROBerMQbaoeri7prgNLXb2EVW1BdBu9uuFhmTvDvW9mxD6HUNsbN.1dpjiUyZMYB6vdxuGnt6 rbepL97IZHPfETDDHWa7zb6Cbgv84.3Oq00GKb.5PQs_pi4kbcA.MwyA1xm8.YHmn0ChEWg5G4fJ VXVrNw8ta6rlUMx536XjqX9LImlXYh8Knp3MdwKaZUItW_A7O85ACoplr40Em7RbpXCyQ9qA4toT NeqwGX90miseVH.OPBic1nn8_QMAgvK_8HjuBcU03zNLMVE.qlX9Ygs8n9eL8cfiNe7qVLH50WIr NwbF4vX4Hf0pGTYwwWjBZgWmVjURpY78QcC4K38dUIeZhcTvhsdAj3nLPDsmwJ3vwS4hSVjwSTyJ V X-Sonic-MF: X-Sonic-ID: c1020d3b-7825-4db4-8fda-c4aa3fd324aa Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Jul 2023 03:46:44 +0000 Received: by hermes--production-ne1-6d679867d5-8p72p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 58927c5c2008f3f146cf299dc095a3f7; Mon, 17 Jul 2023 03:46:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: rsync use with -tmsdosfs mounted file system? file has vanished: . . . From: Mark Millard In-Reply-To: Date: Sun, 16 Jul 2023 20:46:30 -0700 Cc: Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <4B7DD1D6-00F8-436F-A107-2BFD970FAA01@yahoo.com> References: <485EB974-5EF4-4569-9B40-81A474983F33.ref@yahoo.com> <485EB974-5EF4-4569-9B40-81A474983F33@yahoo.com> To: Kevin Oberman X-Mailer: Apple Mail (2.3731.600.7) X-Rspamd-Queue-Id: 4R47LG49Byz3F0V X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jul 16, 2023, at 18:17, Kevin Oberman wrote: > On Sun, Jul 16, 2023 at 1:57=E2=80=AFPM Mark Millard = 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