On Mon, May 20, 2013 at 08:00:18PM +0700, Sthu Deus wrote: > Good time of the day, Darac. > > > Thank You, Darac, for Your time and answer. You wrote: > > > OK, so your directory sizes aren't changing but you're losing space. > > It might be that an application is writing to a deleted file > > (unpacking or streaming to a temporary file, for example). > > Shouldn't dir space also grow even having already removed file ?
No. If the file is deleted, that implies that all references to it have been removed from its parent directories. The only reference left is the one the program is holding. The file has been removed from the directory so (assuming a directory 'knew' its own size), the directory is smaller. In practice, you find the size of a directory by walking all the files within it and summing their sizes. > > > Try running "iotop -a" as root, then use cursors to move the sort > > column to "DISK WRITE". Leave that running for a few minutes and > > you'll be able to see which processes are writing the most data. > > Not so easy: space can stand the same within an hour! :o) That's fine. You should be able to leave iotop running for hours (days, weeks) on end and it will continue to sum up the output. Your only problem is if the disk usage comes from something launched several times and appending to a file (for example a cron job writing to a log). But if that were the case, you'd expect to see the directories swelling, too. > > But i got the point.So it can be an attack: file does not exist > (seen). but occupies whole the free space! - Awesome. Well, yes, I suppose you could see that as an "attack". It IS possible to find deleted files, but if it's not big (and with only 100Mb free space, that's possible) it might be difficult to find.
signature.asc
Description: Digital signature
