<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Two NFS shares with different sizes after rsync in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44514#M10432</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;OnTAP version 8.0.3.P2&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have two 500GB nfs shares, one with 450GB of data and another with zero. Both are mounted on a linux server and an rsync was performed copying data from one nfs share to another.&amp;nbsp; Unfortunately, the destination nfs share is now at 100% disk space used. There should be close to 50GB free.&amp;nbsp; Can someone shed some light on this phenomenon? Currently trying to comprehend dedup and snashots and if they play a role in the mysterious additional 50+GB on the destination share.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks in Advance.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 05 Jun 2025 05:55:08 GMT</pubDate>
    <dc:creator>BENQUINATA</dc:creator>
    <dc:date>2025-06-05T05:55:08Z</dc:date>
    <item>
      <title>Two NFS shares with different sizes after rsync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44514#M10432</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;OnTAP version 8.0.3.P2&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have two 500GB nfs shares, one with 450GB of data and another with zero. Both are mounted on a linux server and an rsync was performed copying data from one nfs share to another.&amp;nbsp; Unfortunately, the destination nfs share is now at 100% disk space used. There should be close to 50GB free.&amp;nbsp; Can someone shed some light on this phenomenon? Currently trying to comprehend dedup and snashots and if they play a role in the mysterious additional 50+GB on the destination share.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks in Advance.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 05:55:08 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44514#M10432</guid>
      <dc:creator>BENQUINATA</dc:creator>
      <dc:date>2025-06-05T05:55:08Z</dc:date>
    </item>
    <item>
      <title>Re: Two NFS shares with different sizes after rsync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44517#M10433</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;This could be because of ASIS.&amp;nbsp; If the source has been deduped, the destination won't reflect that until after a dedupe cycle.&amp;nbsp; Check df -s on the source to see how much data is deduped.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It could also be snapshots.&amp;nbsp; If, for example, you ran a test rsync to the destination then deleted the data, it would be tied up in snaps on the destination until they roll off.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Also, if you don't exclude .snapshots from the rsync, then you risk copying all your source snaps to the destination, which is definitely not what you want.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Bill&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 27 Aug 2013 17:33:27 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44517#M10433</guid>
      <dc:creator>billshaffer</dc:creator>
      <dc:date>2013-08-27T17:33:27Z</dc:date>
    </item>
    <item>
      <title>Re: Two NFS shares with different sizes after rsync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44524#M10434</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thanks Bill.&amp;nbsp; As it turned out, there were multiple factors involved with my issue. First rsync converted hard links to actual files and .snapshot dirs were unintentionally included.&amp;nbsp; Because hardlinks are essential for our application to run properly, I'll be performing an ndumpcopy instead. Hindsight, I should have investigated using ndumpcopy in the first place. Hopefully hardlink are preserved using ndumpcopy. Otherwise, I'll be increasing the quota a bit.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 27 Aug 2013 19:13:53 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44524#M10434</guid>
      <dc:creator>BENQUINATA</dc:creator>
      <dc:date>2013-08-27T19:13:53Z</dc:date>
    </item>
    <item>
      <title>Re: Two NFS shares with different sizes after rsync</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44529#M10435</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;rsync with -H will preserve hard links&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Bill&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 27 Aug 2013 19:22:46 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/Two-NFS-shares-with-different-sizes-after-rsync/m-p/44529#M10435</guid>
      <dc:creator>billshaffer</dc:creator>
      <dc:date>2013-08-27T19:22:46Z</dc:date>
    </item>
  </channel>
</rss>

