FYI: better workaround for updating 'df' info after 'rm' on xfs-vols
Some time ago I reported that after I deleted some large amount of space from one of my xfs volumes, 'df' still showed the original, pre-delete space, though 'du' only showed the expected amount.
Mentioned that I had tried 'sync' to no avail, and had only found umount/mount to cause the figures to synchronize.
Someone suggested cat [1|3] >/proc/sys/vm/drop_caches. That works as a 1 time event, but I've found that doing so only works once/system uptime (if you 'cat' drop_caches' it retains the last value you put there, and doesn't accept a new value with fewer bits set than what you echo'd to it originally (you can change from 1>3, but then not from 3>1 or (3|1)>0. So not so useful.
Prob w/unmounting was inuse file descriptors (being exported by samba to clients being the most likely culprit).
This might not be wise if the FS was actively being written to for a backup, but temporarily doing a
mount -o remount,ro /backups && mount -o remount,rw /backups
seemed to do the trick and cause the disk space to update without me having to stop processes with FD's open on the vol.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Linda Walsh
Some time ago I reported that after I deleted some large amount of space from one of my xfs volumes, 'df' still showed the original, pre-delete space, though 'du' only showed the expected amount.
Sure, because unlinked files might not have their second phase of processing (which releases the disk space) done immediately.
Quoted 2 lines
Mentioned that I had tried 'sync' to no avail, and had only found umount/mount to cause the figures to synchronize.
sync doesn't cause unlinked inodes to be reclaimed and processed, unlike remount,ro, unmount or freeze.
Quoted 1 line
Someone suggested cat [1|3] >/proc/sys/vm/drop_caches.
echo, not cat. It does work every time, whether you see anything obvious or not. And if you want to reclaim inodes, then you want "echo 2 > ..."
Quoted 2 lines
seemed to do the trick and cause the disk space to update without me having to stop processes with FD's open on the vol.
freeze/thaw should do what you want without affecting anything running on the fs at all.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 6 lines
Quoted 2 lines
Someone suggested cat [1|3] >/proc/sys/vm/drop_caches.
echo, not cat. It does work every time, whether you see anything obvious or not. And if you want to reclaim inodes, then you want "echo 2 > ..."
----
Erk...meant echo... too much draino on the braino
(doesn't 3 include '2'? I thought it was a bit mask?)
Quoted 2 lines
freeze/thaw should do what you want without affecting anything running on the fs at all.
---
Thanks... will have to remember / script that ..
Have seen the space not drop for hours!....(literally)..
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 9 lines · Linda Walsh
Quoted 6 lines
Quoted 2 lines
Someone suggested cat [1|3] >/proc/sys/vm/drop_caches.
echo, not cat. It does work every time, whether you see anything obvious or not. And if you want to reclaim inodes, then you want "echo 2 > ..."
----
Erk...meant echo... too much draino on the braino
(doesn't 3 include '2'? I thought it was a bit mask?)
Yes, it is a bit mask. 1 = page cache, 2 = slab cache, 3 = both. Inode reclaim is part of the slab cache reclaim, so page cache reclaim won't make any difference to the behaviour at all.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 21 lines · Dave Chinner
Quoted 4 lines · Linda Walsh
Some time ago I reported that after I deleted some large amount of space from one of my xfs volumes, 'df' still showed the original, pre-delete space, though 'du' only showed the expected amount.
Sure, because unlinked files might not have their second phase of processing (which releases the disk space) done immediately.
Quoted 2 lines
Mentioned that I had tried 'sync' to no avail, and had only found umount/mount to cause the figures to synchronize.
sync doesn't cause unlinked inodes to be reclaimed and processed, unlike remount,ro, unmount or freeze.
Quoted 1 line
Someone suggested cat [1|3] >/proc/sys/vm/drop_caches.
echo, not cat. It does work every time, whether you see anything obvious or not. And if you want to reclaim inodes, then you want "echo 2 > ..."
Quoted 6 lines
Quoted 3 lines
xfs_mount-o remount,ro + rw
seemed to do the trick and cause the disk space to update without me having to stop processes with FD's open on the vol.freeze/thaw should do what you want without affecting anything running on the fs at all.
----
It doesn't work at al.
.... I've deleted off 2.4T from an 11T volume in about 15 files. du reflects the actions:
Ishtar:/backups> du -sxh /backups/
9.6T /backups/
Ishtar:/backups> df .
df does not:
Filesystem Size Used Avail Use% Mounted on/dev/mapper/Backups-Backups 11T 11T 14G 100% /backups
Any stats you want to debug this?
Ishtar:/backups> xfs_info /backups
meta-data=/dev/mapper/Backups-Backups isize=256 agcount=11, agsize=268435440 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=2929458176, imaxpct=5
= sunit=16 swidth=96 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=32768, version=2
= sectsz=512 sunit=16 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
----
from to extents blocks pct
1 1 861 861 0.02
2 3 1424 3587 0.10
4 7 913 3785 0.10
16 31 2 52 0.00
512 1023 2 1164 0.03
1024 2047 1 1833 0.05
2048 4095 2 5972 0.17
8192 16383 1 8688 0.24
32768 65535 2 94647 2.62
65536 131071 2 190992 5.29
262144 524287 3 1230194 34.10
1048576 2097151 1 2066103 57.27total free extents 3214
total free blocks 3607878 ### well at 4k/block, that's 1.4T which is about
right
average free extent size 1122.55xfs_db> q
So why df
Ishtar:/backups> df .
Filesystem Size Used Avail Use% Mounted on/dev/mapper/Backups-Backups 11T 11T 14G 100% /backups
Ishtar:law/test> mount -l|grep backups/dev/mapper/Backups-Backups on /backups type xfs (rw,noatime,nodiratime,swalloc,attr2,largeio,inode64,allocsize=131072k,logbsize=256k,sunit=128,swidth=768,noquota) [Backups]
--- reality check -- swidth DOES mean total width, right? i.e. 768/128 = 6
disks wide which is a
correct number of data disks in the array.
BTW, I'm wondering if my alignment is important or correct on it:
parted -l on the volume shows:
Disk /dev/sdb: 12.0TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt_sync_mbr
Number Start End Size File system Name Flags 1 17.4kB 12.0TB 12.0TB backup lvm
(i.e. it's not starting @ 0)
sudo pvs /dev/sdb1 -o +pe_start,pvseg_start
PV VG Fmt Attr PSize PFree 1st PE Start
/dev/sdb1 Backups lvm2 a-- 10.91t 0 512.00k 0
sudo vgs Backups -o +vg_mda_size,vg_mda_copies,vg_extent_size
VG #PV #LV #SN Attr VSize VFree VMdaSize #VMdaCps Ext
Backups 1 1 0 wz--n- 10.91t 0 188.00k unmanaged 4.00m
my system's xfs settings:
Ishtar:/proc/sys/fs/xfs> for i in *
do
printf "%30s: %-10s\n" "$i" $(<"$i")
done
age_buffer_centisecs: 1500
error_level: 3
filestream_centisecs: 3000
inherit_noatime: 1
inherit_nodefrag: 1
inherit_nodump: 1
inherit_nosymlinks: 0
inherit_sync: 1
irix_sgid_inherit: 0
irix_symlink_mode: 0
panic_mask: 0
rotorstep: 1 speculative_prealloc_lifetime: 300
stats_clear: 0
xfsbufd_centisecs: 100
xfssyncd_centisecs: 3000
---------------
Also I don't understand. does irix_sgid_inherit mean something other than directories created in a dir with the sgid bit set also get it set with the same group ownership?
As I just tested it .. made a dir set the group & chmod g+s.. made a dir in it, and it got created w/same group and w/sgid bit set.
But looking at the above, I'd think the sgid bit wasn't supposed to be inherited...(I can go look it up, but just looked strange).
----
In the ~54 minutes it took to write this:
Quoted 1 line
df /backups
Filesystem Size Used Avail Use% Mounted on/dev/mapper/Backups-Backups 11T 11T 14G 100% /backups
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs