Excerpts from Mike Fedyk's message of 2010-12-07 14:16:55 -0500: > On Tue, Dec 7, 2010 at 10:44 AM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > > Excerpts from Tsutomu Itoh's message of 2010-12-07 02:59:52 -0500: > >> Hi, > >> > >> I think that the disk allocation size of each file becomes a monotone increase > >> when the file is made. > >> But, it sometimes return to 0. ÂIs it correct? > > > > Well, there's a window during the processing of delayed allocation where > > we don't have the bytes recorded as delalloc and we don't have the bytes > > recorded in the inode yet. ÂThat's why they are showing up as zero. > > > > We don't call inode_add_bytes() until after we insert the extent, but we > > drop the delalloc byte count on the file before the IO is done. > > > > Fixing it will be a little tricky because all the extent accounting > > assumes the inode_add_bytes happens at extent insertion time. > > > > How does opening the inode with O_APPEND during this window know where > to write the bytes? If it's a pointer/cursor to the EOF then that > size could be used during the window. Is that right? This counter records the number of blocks allocated to the file, and reading it with ls -l or stat is somewhat racey by nature. Most of the time its fine, btrfs just has a really big window where the results from ls -l seem wrong. But, the counter really means nothing to the btrfs internals. When we do file operations we go based on the extent pointers we find in the tree and i_size (i_size is strictly maintained). The incorrect results are confusing but they don't hurt the metadata itself. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
