Deleted files on a SMB-share - Files gone, space still allocated

Zwentendorf · 02-28-2009, 12:03 PM

I was re-organizing some of my shared files on a Vista box, and ran into a bunch of duplicate files on my Fedora file server. Those files were on a Samba-shared volume that was mapped as a network drive. Now, instead of deleting them the usual way, i.e. launching a WinSPC session, I did it via Windows Explorer. A big mistake.

The files are indeed gone, but I only gained ~500 MB of free space, for 62 GB of deleted files. The actual volume is ext3. Any ideas on fixing this allocation problem would be much appreciated.

mesiol · 02-28-2009, 12:14 PM

Hi,

are you really sure the files are gone? Possibly there're file pointers open to the files, what means they are not shown in the file system, but space will first be shown as free after the pointers are closed.

Try

Code:

 lsof

and take a look if there's a software having the file open.

Zwentendorf · 02-28-2009, 12:29 PM

Quote:

Originally Posted by mesiol

Hi,

are you really sure the files are gone? Possibly there're file pointers open to the files, what means they are not shown in the file system, but space will first be shown as free after the pointers are closed.

Try

Code:

 lsof

and take a look if there's a software having the file open.

Thanks, hadn't thought of that. I verified that the files were not in use, and rebooted the box to make sure. Unfortunately this didn't fix the problem.

mesiol · 03-01-2009, 12:16 AM

Hi,

this sound really strange to me. Did you verify how many diskspace the existing files on the disk allocate?

Try

Code:

 du -sk MY_DIRECTORY_WHERE_I_DELETED_FILES

and

Code:

 df -k

and compare the outputs.

I'm not aware of any kind of bug producing problems like this on a ext3 filesystem.

Zwentendorf · 03-01-2009, 05:04 AM

Quote:

Originally Posted by mesiol

Hi,

this sound really strange to me. Did you verify how many diskspace the existing files on the disk allocate?

Try

Code:

 du -sk MY_DIRECTORY_WHERE_I_DELETED_FILES

and

Code:

 df -k

and compare the outputs.

I'm not aware of any kind of bug producing problems like this on a ext3 filesystem.

Strange indeed, but I think you've actually lead me to the root of the problem. Yesterday I detached all other drives from the box, and ran e2fsck. Nothing changed.

Now by comparing the actual allocated space, and the df -k -output it all came back to me.

Code:

 
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     188039012 175953472   2533668  99% /
/dev/sda5               202219     34245    157534  18% /boot
tmpfs                   256488       108    256380   1% /dev/shm
/dev/sda3            239722336  42511256 197211080  18% /media/2002_01_01_09:00

I had to get the box running quickly after a disk failure one day, and installed Fedora on an old 320GB linkstation drive I had lying around. Clearly I didn't pay too much attention and the end result was a confused filesystem. As you can see, the system thinks that sda3 has 189 GB of free space left, while 168 GB are used on the first volume. 189+168=357, which is a bit of a paradox on a 320 GB disk.

The strange thing is that this mess had actually worked until yesterday. I never touched sda3, to make sure I don't fill the drive to capacity. All file operations still work perfectly, including deleting files locally. It's strange, because the deleted files were on the volume that's still 99% full, but I guess the missing free space can be blamed on the confused filesystem & Samba.