[OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference?
Dan McDonald
danmcd at omniti.com
Wed Apr 29 19:51:18 UTC 2015
> On Apr 29, 2015, at 3:21 PM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
>
> We have a filesystem/dataset with no snapshots,
You're sure about no snapshots? "zfs list -t snapshot" has surprised me once or twice in the past. :-/
> no subordinate
> filesystems, nothing complicated (and no compression), that has a
> drastic difference in space used between what df/zfs list/etc report at
> the ZFS level and what du reports at the filesystem level. ZFS says
>
> NAME PROPERTY VALUE SOURCE
> fs0-core-01/cs/8 used 70.5G -
> fs0-core-01/cs/8 usedbydataset 70.5G -
>
> On the other hand, 'du -h' says 17 GB, which is what we'd expect.
> More alarmingly, this dataset seems to keep steadily growing at the
> ZFS level despite 'du -h' figures staying constant or even going down.
> On April 2nd it was reporting a 'du -h' of 22 GB but 48 GB used at the
> ZFS level; as you can see, it's added 22 GB of ZFS usage in less than
> a month while losing 5 GB at the user level.
This almost sounds like there's a process with an open file, which was removed, but the process in question still has it open.
pfiles(1) on your processes may be very helpful here.
> What sort of things should I be looking at to try to figure out why
> this is happening, including with eg zdb? Are there any obvious reasons
> why this would be happening? Is there any easy way to fix this short of
> 'copy all data to a new dataset, destroy old dataset, put new dataset
> in the place of the old?'
I take it that a reboot of this machine (which would kill any processes with an open-but-deleted file) has already been done?
Dan
More information about the OmniOS-discuss
mailing list