لماذا يقول df إن القرص ممتلئ بينما يقول du غير ذلك؟

لماذا يعرض df أن القرص ممتلئ بينما يعرض du نتيجة مختلفة

يعرض df القرص ممتلئاً، بينما لا يستطيع du العثور على المساحة المستخدمة لأن عملية ما زالت تحتفظ بملف حُذف. يؤدي حذف الملف إلى إزالة اسمه من الدليل. ولا تُحرَّر كتل البيانات إلا بعد إغلاق آخر واصف ملف مفتوح يشير إلى ذلك inode. يتنقل du بين الأسماء، لذلك لا يحسب شيئاً. أما df فيطلب من نظام الملفات عدد الكتل المخصّصة، لذلك يظل يحسب الملف الذي لم يعد له اسم.

يعيد هذا الدليل إنتاج الحالة على VPS يعمل بنظام Ubuntu عادي، باستخدام أدوات مثبتة مسبقاً. ثم يحدد العملية التي تحتفظ بالملف عبر /proc، ويحرر المساحة من دون إعادة التشغيل. وتشمل الأسباب الأخرى للعرض نفسه ما يلي: امتلاء جدول inode من دون وجود إدخالات حرة، ووجود ملفات مخفية أسفل نقطة تحميل، ووجود كتل محجوزة لحساب root.

نفّذ كل أمر واقرأ مخرجاتك بنفسك. تعتمد القيم على قرصك، لذلك قارن النتيجة قبل التغيير وبعده على جهازك، ولا تقارنها برقم وارد في الدليل.

ما الذي يحسبه df وما الذي يحسبه du

يسأل df (المساحة الحرة على القرص) كل نظام ملفات مركّب عن حساباته الخاصة: عدد الكتل الموجودة، وعدد الكتل المخصّصة، وعدد الكتل الحرة. لا يفتح أي دليل. وتشمل النتيجة كل كتلة مخصّصة، بما في ذلك الكتل التابعة لملف لا يشير إليه أي إدخال في دليل.

يفعل du (استخدام القرص) العكس. يبدأ من المسار الذي تحدده، ويقرأ الأدلة، ويحصل على معلومات كل إدخال يعثر عليه، ثم يجمع الكتل. لا يمكنه رؤية ملف بلا اسم. وينطبق الأمر نفسه على أي دليل لا يُسمح له بقراءته، ولذلك يحصل المستخدم العادي على إجمالي أصغر من الإجمالي الذي يحصل عليه root. شغّل du باستخدام sudo قبل أن تستنتج أي شيء من المقارنة.

هناك خياران مهمان عند مقارنة الأداتين.

• يبقي -x du ضمن نظام ملفات واحد. من دونه، يدخل du / إلى كل نظام ملفات مركّب أسفل /، وينتج إجمالياً لم يكن df / يقيسه أصلاً.
• يطبع -s سطراً واحداً للتلخيص لكل وسيطة، بدلاً من سطر واحد لكل دليل.

بهذا تحصل على الأمرين اللذين يجب تشغيلهما جنباً إلى جنب على نظام الملفات المعني.

df -h /
sudo du -xhs / 2>/dev/null

يعطي df النتيجة فوراً. يستغرق du دقائق على نظام ملفات كبير، لأنه يحصل على معلومات كل ملف أثناء مروره. عندما يختلف الإجماليان كثيراً، وكان du قد شُغّل بصفة root مع -x، تكون المساحة المفقودة مخصّصة لشيء لا يملك اسماً.

أعد إنتاج عدم التطابق عمداً

نفّذ ذلك على VPS تجريبي. كل ما يلي يستخدم bash وcoreutils، لذلك لن يتم تثبيت أي شيء.

سجّل الحالة الأولية لنظام الملفات الذي يحتوي على /var/tmp.

cd /var/tmp
df -h .
df --output=used -B1 .

يطبع الأمر الثاني عدد البايتات المستخدمة دون تقريب، ما يجعل التحقق في النهاية دقيقاً.

أنشئ الآن ملفاً. يُحدَّد حجمه من المساحة الحرة التي يبلّغ عنها الجهاز نفسه، لذلك تناسب التجربة أي قرص لديك.

free=$(df --output=avail -B1 . | tail -n 1)
fallocate -l $((free / 10)) ghost.bin
ls -l ghost.bin
df -h .

$(...) هو استبدال الأوامر: يشغّل shell الأمر الموجود بداخله، ويصبح الناتج قيمة free. إذا كانت هذه الصياغة جديدة عليك، يشرح استبدال الأوامر في bash ذلك بالتفصيل. يحجز fallocate الكتل الفعلية من دون الكتابة إليها، ولذلك ينتهي فوراً. إذا كان نظام الملفات لا يدعم ذلك، يفشل الأمر، ويؤدي head -c $((free / 10)) /dev/zero > ghost.bin الغرض نفسه عبر كتابة البايتات.

قارن هذا df -h . بالذي سجّلته. ازداد العمود المستخدم، وتقلّص العمود المتاح.

أبقِ الملف مفتوحاً من عملية أخرى، ثم احذفه.

sleep infinity < ghost.bin &
holder=$!
rm ghost.bin
ls -l ghost.bin
df -h .
sudo du -xhs . 2>/dev/null

إعادة التوجيه هي جوهر الحيلة. يبدأ sleep infinity < ghost.bin & عملية في الخلفية يكون إدخالها القياسي هو ذلك الملف، لذلك يفتح shell الملف ويمرر واصف الملف إلى sleep، الذي يبقيه مفتوحاً. يحتوي $! على معرّف العملية لمهمة الخلفية تلك. ثم يزيل rm الاسم، بينما لا يزال واصف الملف مفتوحاً.

اقرأ الناتج. لا يستطيع ls العثور على الملف لأن الاسم اختفى. عاد du إلى قيمة قريبة من قيمته الأولية لأنه يتنقل بين الأسماء. لم يتغير df لأن الكتل لا تزال محجوزة. أصبح هناك الآن اختلاف بين نظام الملفات وشجرة الأدلة، والفجوة بينهما هي الملف الذي حذفته للتو.

العثور على العملية التي تحتفظ بالملف المحذوف

يظهر كل واصف ملفات مفتوح ضمن /proc/<pid>/fd/ كرابط رمزي إلى الملف الذي يشير إليه. عند إلغاء ربط الملف، تضع النواة علامة تشير إلى أن هدف ذلك الرابط محذوف. لذلك، يعني العثور على العملية المالكة العثور على رابط يحمل هدفه تلك العلامة.

sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null

يطابق -lname هدف الرابط الرمزي بدلاً من اسمه، ويطبع %p مسار واصف الملفات، بينما يطبع %l ما يشير إليه. معرّف العملية هو العنصر الثاني في المسار الذي يطبعه. شغّل الأمر باستخدام sudo، وإلا فلن تتمكن من قراءة /proc/<pid>/fd إلا للعمليات الخاصة بك. يؤدي توجيه stderr إلى إسقاط الرسائل الناتجة عن العمليات التي تنتهي أثناء اجتياز find للملفات.

يحتفظ خادم مشغول بعدة ملفات محذوفة في أي وقت، ومعظمها صغير وغير ضار. رتّبها حسب الحجم حتى تبقى الملفات المهمة فقط في أعلى القائمة.

sudo bash -c 'for fd in /proc/[0-9]*/fd/*; do
  target=$(readlink "$fd" 2>/dev/null) || continue
  case "$target" in
    *"(deleted)") echo "$(stat -Lc %s "$fd" 2>/dev/null) $fd $target" ;;
  esac
done' | sort -rn | head

يتتبع stat -L الرابط إلى inode نفسه، لذلك يبلّغ %s عن حجم الملف الذي لم يعد له اسم. يؤدي الترتيب حسب هذا الرقم إلى وضع أكبر ملف أولاً.

حدّد بعد ذلك العملية المرتبطة بواصف الملفات الفائز. يحتوي المسار الموجود أعلى القائمة على الرقمين المطلوبين، لذا خزّنهما أولاً في متغيرين، واستبدل PID وN بالقيم التي أظهرتها قائمتك.

pid=PID
n=N
ps -o pid,user,etime,args -p "$pid"
sudo stat -L "/proc/$pid/fd/$n"

يُسمّي ps البرنامج ويعرض مدة تشغيله. ويطبع stat -L حجم inode المحذوف وعدد الكتل المخصّصة له. يجيب الأمران معاً عن السؤال المهم: ما الخدمة التي تُبقي هذا الملف قيد الاستخدام؟

إذا كان الجهاز يحتوي مسبقاً على lsof، فإن sudo lsof +L1 يسرد الملفات المفتوحة التي انخفض عدد روابطها إلى الصفر، ويعرض أحجامها في جدول واحد. لا يكون هذا البرنامج مثبتاً في صورة Ubuntu الدنيا، كما قد يفشل تثبيت حزمة على نظام ملفات لا تتوفر فيه مساحة حرة. لذلك، فإن اجتياز /proc هو الإصدار الذي يعمل دائماً.

حرّر المساحة من دون إعادة تشغيل

تُصلح إعادة التشغيل المشكلة فعلاً، لكنها ليست الخطوة الأولى الصحيحة: فهي توقف الخدمة وتُتلف الأدلة. توجد 4 خيارات أقل تأثيراً، ويجب تجربتها بهذا الترتيب.

أولاً، انسخ البيانات إلى مكان آخر إذا كنت لا تزال تريدها. تؤدي قراءة مسار الواصف إلى قراءة inode الحي.

sudo cp /proc/<pid>/fd/<n> /root/recovered.log

هذه هي الحالة الوحيدة التي يسهل فيها استعادة ملف محذوف، ولذلك يبدأ استرداد الملفات المحذوفة باستخدام rm -rf بالسؤال عما إذا كانت عملية ما لا تزال تُبقي الملف مفتوحاً. بعد إغلاق آخر واصف، يختفي هذا المسار.

ثانياً، أفرغ الملف عبر الواصف. يقود المسار /proc إلى inode نفسه، ولذلك يؤدي اقتطاعه إلى تحرير الكتل مع استمرار العملية في العمل.

sudo truncate -s 0 "/proc/$pid/fd/$n"
df -h /

يعمل هذا بصورة سليمة عندما تكون العملية الكاتبة قد فتحت الملف في وضع الإلحاق، لأن كل كتابة تذهب عندئذ إلى النهاية الحالية للملف. أما إذا لم تكن قد فعلت ذلك، فتحتفظ العملية بموضع الكتابة القديم، ولذلك تقع الكتابة التالية بعيداً داخل الملف وتعيد إنشاءه مع فجوة في بدايته. لا تُخصَّص مساحة للفجوة، لذلك تبقى الكتل محررة، ويحتفظ df بالمساحة التي أعادها للتو. الذي يعود هو الحجم وحده: شغّل sudo stat -L "/proc/$pid/fd/$n" مرة أخرى بعد أن تكتب العملية، وسيعرض الحجم القديم بجانب عدد كتل لا يطابقه بعد الآن. أعد تشغيل العملية عندما تريد أن يبدأ الحجم من الصفر أيضاً.

ثالثاً، اطلب من الخدمة إعادة فتح سجلاتها. يُعد daemon الذي حُذف ملف سجله أثناء استخدامه له الحالة الواقعية الشائعة لهذه المشكلة. تعيد كثير من daemons فتح ملفات سجلاتها عند تلقي إشارة: يستخدم nginx الإشارة SIGUSR1، ويستخدم rsyslog الإشارة SIGHUP. راجع وثائق daemon الذي تتعامل معه بدلاً من التخمين، لأن إرسال الإشارة الخاطئة إلى daemon خاطئ يؤدي إلى إيقافه.

sudo systemctl kill -s USR1 nginx

رابعاً، أعد تشغيل الوحدة. يغلق sudo systemctl restart <unit> كل واصف كان يحتفظ به process القديم، ولذلك تعود الكتل مؤكداً. في المثال السابق، الحائز هو sleep الذي شغّلته بنفسك، لذا يكفي إنهاؤه.

kill $holder
df -h .
df --output=used -B1 .
sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null

قارن البايتات المستخدمة بالقيمة التي سجلتها قبل إنشاء الملف. تتطابق القيمتان مجدداً، ولم يعد find يعرض واصفك. يُعد التحقق باستخدام الأمر نفسه الذي اكتشف المشكلة عادةً تستحق المحافظة عليها.

تكون مراقبة تغير هذه القيمة أسهل من تشغيل df يدوياً مراراً. يكرر watch تكرار أمر بفاصل زمني ثابت الأمر ويعيد طباعة الناتج في موضعه، ولذلك يعرض watch df -h / تغير عمود الاستخدام مع عودة المساحة.

عندما تتطابق الإجماليات ويبقى القرص ممتلئاً

إذا تطابق df مع du -x الخاص بـroot، فلا يوجد ملف محذوف مرتبط بالمشكلة. تكون الأسباب المتبقية مختلفة بطبيعتها، ولكل سبب منها فحصه الخاص.

نفاد الـinodes وليس الكتل

يحتوي inode على البيانات الوصفية لملف واحد. ينشئ ext4 عدداً ثابتاً من inodes عند إنشاء نظام الملفات، لذلك قد ينفد نظام الملفات من inodes مع بقاء كتل حرة فيه. عندها يفشل إنشاء ملفات جديدة رغم أن df -h يعرض مساحة متاحة.

df -h /
df -i /

يعدّ الأمر الأول الكتل، ويعدّ الأمر الثاني الـinodes. قارن عمود الاستخدام في كل منهما. إذا كان استخدام الكتل منخفضاً، بينما بلغ استخدام الـinodes حده، فالمشكلة هي وجود عدد كبير جداً من الملفات الصغيرة جداً.

يرفض df الخيارين -i و--output في الاستدعاء نفسه. لذلك، عندما تريد قراءة الأعداد الخام أو تمريرها إلى أمر آخر، حدّد حقول الـinodes بالاسم واترك -i معطلاً.

df --output=itotal,iused,iavail,ipcent /

تعرض هذه الأعمدة بيانات المحاسبة نفسها التي يطبعها df -i، لكن بصيغة يمكنك تحليلها.

اعثر على الملفات عبر عدّ الإدخالات بدلاً من عدّ البايتات.

sudo du --inodes -x -d 1 / 2>/dev/null | sort -rn | head

كرّر الأمر نفسه على مستوى أدنى واحد داخل الدليل الذي ظهر في المقدمة، إلى أن تصل إلى الشجرة التي تنشئ الملفات. إذا كان du لا يدعم --inodes، فإن sudo find /var -xdev -type f | wc -l يعدّ الشجرة الفرعية بالطريقة الأبطأ.

الحل هو حذف هذه الملفات أو نقلها. لا يمكنك إضافة inodes إلى نظام ملفات ext4 موجود، لأن العدد يثبت وقت mkfs. لذلك، رفع العدد يعني إعادة إنشاء نظام الملفات والاستعادة من نسخة احتياطية. يخصص XFS الـinodes عند الحاجة، لذلك لا يواجه حداً ثابتاً بالطريقة نفسها. تصل الآلة التي تشغّل الحاويات إلى كلا الحدين أسرع من معظم الآلات، لأن طبقات الصور تحتوي على عدد كبير من الملفات الصغيرة. على تلك الآلة، تُعدّ إزالة استخدام Docker للقرص على VPS الحل المحدد، وتستعيد مساحة أكبر بكثير مما يحققه فحص عام لنظام الملفات.

مساحة مخفية تحت نقطة تحميل

يمكن للدليل أن يحتوي على ملفات قبل تحميل أي شيء عليه. حمّل نظام ملفات فوق ذلك الدليل، وستبقى الملفات الموجودة تحته في مكانها تماماً: ما زالت مخصّصة، وما زال df يحتسبها، لكن لم يعد الوصول إليها ممكناً بالاسم. لا يستطيع du رؤيتها لأن نقطة التحميل تغطيها.

اعرض ذلك باستخدام tmpfs، الذي لا يحتاج إلى مساحة قرص إضافية. يتطلب هذا الجزء جهازاً مسموحاً لك بإجراء عمليات التحميل عليه، ولذلك يعمل على KVM VPS.

sudo mkdir -p /srv/covered
sudo cp /etc/services /srv/covered/
ls /srv/covered
sudo mount -t tmpfs tmpfs /srv/covered
ls /srv/covered
sudo umount /srv/covered
ls /srv/covered

يعرض ls الأوسط دليلاً فارغاً. لم تنتقل النسخة إلى أي مكان؛ فما زالت على نظام الملفات الجذري، وستظهر مجدداً فور إلغاء التحميل. تخيّل الآن خدمة كتبت السجلات إلى ذلك المسار لمدة شهر قبل أن يحمّل أحدهم وحدة تخزين فوقه.

للعثور على الملفات الفعلية على خادم قيد التشغيل، حمّل نظام الملفات الجذري مرة ثانية في مكان آخر. يعرض bind mount نظام ملفات واحداً من دون أن يعرض أنظمة الملفات المحمّلة داخله.

sudo mkdir -p /mnt/rootcheck
sudo mount --bind / /mnt/rootcheck
sudo du -xhs /mnt/rootcheck/* 2>/dev/null | sort -h
sudo umount /mnt/rootcheck

كل ما يظهر في تلك القائمة ولا يظهر تحت المسار المعتاد مدفون تحت نقطة تحميل. ألغِ تحميل bind mount عند الانتهاء، وإلا فسيحتسب du لاحقاً، من دون -x، الملفات نفسها مرتين.

الكتل المحجوزة لحساب root

يخصّص ext4 جزءاً من كتله لحساب root، حتى لا يمنع امتلاء القرص حساب root من تسجيل الدخول وإصلاح الجهاز. تصل العملية التي تعمل بحساب مستخدم عادي إلى هذا الحد أولاً، بينما يظل df يعرض مقداراً صغيراً من المساحة. اقرأ الإعداد من نظام الملفات لديك بدلاً من افتراض القيمة الافتراضية.

dev=$(df --output=source / | tail -n 1)
sudo tune2fs -l "$dev" | grep -i 'block count'

يعرض ذلك العدد الإجمالي للكتل وعدد الكتل المحجوزة بالوحدات نفسها، لذلك تكون النسبة بينهما مباشرة. يعرض df العمود المتاح باعتباره المساحة التي لا يزال بإمكان المستخدم العادي استخدامها، ولهذا يكون مجموع المساحة المستخدمة والمساحة المتاحة أصغر من الحجم. هذا الفرق هو المساحة المحجوزة.

غيّر الإعداد باستخدام sudo tune2fs -m <percent> "$dev". يُطبَّق التغيير فوراً ولا يحتاج إلى إعادة تركيب نظام الملفات. من المعقول خفض المساحة المحجوزة على نظام ملفات منفصل للبيانات. أما في نظام الملفات الجذري، فاترك مساحة كافية ليتمكن root من الكتابة، لأن إصلاح نظام ملفات جذري لا يحتوي على أي مساحة خالية يصبح أصعب بكثير. يعمل tune2fs مع ext2 وext3 وext4. لا يوفّر XFS إعداداً مماثلاً.

متى يضللك du عند استخدامه وحده

تؤدي أربع ممارسات في du إلى إجماليات تبدو غير صحيحة.

• الروابط الصلبة: يحسب du inode مرة واحدة حتى عندما تشير عدة أسماء إليه، لذلك يعرض مجلد يحتوي على عدد كبير من الروابط الصلبة قيمة أقل من مجموع ملفاته.
• الملفات المتناثرة: يعرض du الكتل المخصّصة فعلياً، بينما يعرض ls -l الحجم الظاهري. أضف --apparent-size لعرض القيمة الأخرى.
• الصلاحيات: عند تشغيله كمستخدم عادي، يتجاوز du ما لا يستطيع قراءته، ويعرض قيمة أقل من الفعلية. والأخطاء التي يطبعها هي ما يعيد الأشخاص توجيهه إلى /dev/null ثم يتوقفون عن قراءته.
• حدود أنظمة الملفات: من دون -x، يحسب du / كل نظام ملفات مركّب أسفل /، لذلك قد يتجاوز إجماليه القيمة التي يعرضها df /.

ولهذا السلوك في df أهمية أيضاً. فهو يعرض كل نظام ملفات على حدة، لذلك شغّله على المسار الدقيق الذي تستهدفه عملية الكتابة الفاشلة. ويمتلئ /boot منفصل وفق جدول زمني خاص به مع تراكم حزم النواة، كما أن إزالة النوى القديمة على Ubuntu تختلف عن تفريغ المساحة في /.

ترتيب عملي للتعامل مع حادثة فعلية

1. شغّل df -h <path> وdf -i <path> على نظام الملفات الذي كانت عملية الكتابة الفاشلة تستهدفه، وليس على / بشكل تلقائي.
2. شغّل sudo du -xh -d 1 <mountpoint> 2>/dev/null | sort -h، ثم انتقل داخل أكبر دليل.
3. إذا لم يتمكن du من تفسير المساحة التي يعرض df أنها مستخدمة، فابحث في /proc عن ملفات محذوفة ما زالت مفتوحة.
4. إذا تطابقت النتيجتان، فنفّذ bind mount لنظام الملفات في موقع آخر، وابحث عن ملفات موجودة أسفل نقطة mount.
5. إذا كان استخدام inodes هو الذي بلغ الحد، فأحصِ الملفات بدلاً من البايتات.

كل خطوة هنا تتضمن أمراً يمكنك قراءة ناتجه. وهذا هو الفرق بين إصلاح المشكلة والتخمين بشأنها.

FAQ

لماذا يعرض df القرص ممتلئاً بينما يعثر du على مساحة أقل بكثير؟

السبب المعتاد هو ملف حُذف بينما كانت إحدى العمليات لا تزال تفتحه. يؤدي حذف الملف إلى إزالة مدخله من الدليل، لذلك لا يجد du اسماً يتتبعه ويتوقف عن احتسابه. تبقى inode وكتلها مخصّصة حتى يُغلق آخر واصف، بينما يحسب df الكتل المخصّصة. ابحث في /proc/<pid>/fd عن روابط رمزية يشير هدفها إلى ملف معلَّم بأنه محذوف، وستجد الملف والعملية التي تحتفظ به مفتوحاً. قبل الوثوق بالمقارنة، تأكد من تشغيل du بصلاحيات root ومع -x، لأن المستخدم العادي يتجاوز بصمت الأدلة التي لا يستطيع قراءتها.

كيف أعثر على ملف محذوف لا يزال مفتوحاً من دون lsof؟

استخدم السجل الخاص بالنواة للواصفات المفتوحة. يسرد sudo find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null كل واصف يشير إلى ملف بلا اسم، ويظهر معرّف العملية داخل المسار الذي يطبعه. يعرض sudo stat -Lc %s حجم الملف في أحد مسارات الواصفات هذه، لذا يمكنك ترتيبها واختيار الملف المهم. لا يتطلب ذلك أي حزمة، وهذا مهم لأن تثبيت حزمة على نظام ملفات لا تتوفر فيه مساحة حرة قد يفشل.

هل يمكنني تحرير المساحة من دون إنهاء العملية؟

أحياناً. يصل sudo truncate -s 0 /proc/<pid>/fd/<n> إلى inode نفسها عبر الواصف ويحرر كتلها بينما تستمر العملية في العمل. يكون ذلك أنسب عندما فتحت العملية الملف في وضع الإلحاق، لأن عمليات الكتابة تذهب دائماً إلى النهاية الحالية. إذا لم يكن الأمر كذلك، يبقى إزاحة الكتابة في موضعها، وتعيد الكتابة التالية إنشاء الملف مع فجوة في بدايته، لذلك يعود الحجم المبلّغ عنه إلى الظهور بينما تبقى الكتل الموجودة أسفل الفجوة حرة. إعادة تشغيل الوحدة، أو إرسال إشارة إليها لإعادة فتح سجلاتها باستخدام الإشارة التي تحددها وثائقها، هو الحل الذي لا يترك ملفاً متفرقاً.

يعرض df مساحة حرة، لكن عمليات الكتابة لا تزال تفشل. ما الأسباب الأخرى المحتملة؟

تحقق من inodes باستخدام df -i على المسار نفسه، لأن نظام الملفات الذي يحتوي على كتل حرة ولا يحتوي على inodes حرة يرفض إنشاء ملفات جديدة. تحقق مما إذا كانت عملية الكتابة تعمل كمستخدم غير root على نظام ملفات ext4 لم تتبقَّ فيه إلا الكتل المحجوزة؛ وسيعرض sudo tune2fs -l ذلك على الجهاز. تأكد من أنك تقرأ نظام الملفات الذي تستهدفه عملية الكتابة فعلياً، لأن /boot أو /var منفصلاً قد يمتلئ بصورة مستقلة عن /.

لماذا يعرض du إجمالياً أكبر من df؟

يعبر du من دون -x إلى كل نظام ملفات مركّب تحت المسار الذي قدمته له، لذلك يجمع عدة أنظمة ملفات، بينما يصف df نظام ملفات واحداً. وتجعل bind mounts الأمر أسوأ، لأن الملفات نفسها تُحتسب مرة تحت كل مسار تظهر فيه. أضف -x لإبقاء du ضمن نظام ملفات واحد، وامنح df المسار نفسه، حتى يصف الأمران الشيء نفسه.