David McPaul <dlmcpaul@xxxxxxxxx> wrote: > 2009/6/24 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> > > Can you give me an example on how to reproduce this? If you copy > > lots > > of small files, this might just be natural, though. > I run 2 partitions, a HaikuDev and a HaikuTest both 4Gb in size [...] > I then copy with Tracker my programming directory from HaikuDev to > HaikuTest. This directory is about 500Mb in size (essentially haiku > source plus generated directory). The haiku source alone is 853 MB, without any generated files. So it'll be a bit more than just 500 MB when there is a generated directory as well. > I can then watch the free space on Haiku Disk start dropping until it > hits 0 and cannot copy more files. > > If I do the copy in parts and then unmount the destination between > parts I can get the files across. The unmount I expect does a sync > as > it takes a while to unmount. But running sync manually has no effect > (perhaps sync only syncs the boot drive?) "sync" just has nothing to do with it - the problem seems to be the preallocation, and for directories, this is only cut back when the vnode is flushed, which, for example, happens when you unmount a file system. > I always figured that once checkfs was working for me I would be able > to run it and get a better idea where all the space is going. > > Someone mentioned that pre-allocation does not always trim back a > file > or directory once it has finished copying? Files are always trimmed back on close - for directories, there is no such mechanism, so it's currently done when the its vnode is flushed. If you have enough memory, this might happen too seldom - I'ved just tried to reproduce this problem with only 712 MB, and the difference between a "svn co", and later (when all vnodes were flushed due to the copy) was 300 MB, ie. disk usage dropped from 1.4 GB to 1.1 GB. How much memory do you have on your system? Also, rebooting does not unmount the volume, so preallocation is "lost" on disk. Losing the preallocation would also happen on crashs, but it's usually not that bad. I guess I should rethink when and how BFS trims back directory inodes. The haiku sources have 85556 files today, and over 20000 directories. So the maxium loss should be around 1.2 GB which is a bit much to be acceptable. If directories would only preallocate 4K, the maximum loss would only be 80 MB which I think is quite okay and would be a pretty simple solution. Bye, Axel.