[haiku-development] Re: Filesystem corruption and Alpha-1

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.

Other related posts: