On Tue, Dec 7, 2010 at 11:29 AM, Chris Mason <chris.mason@oracle.com> wrote:
quoted text > 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@oracle.com> 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.
>
I see. Is it using per-cpu vars or something similar?
quoted text > 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).
>
Would it be too heavy of an operation to have stat walk the btrfs tree
to get its data?
quoted text > The incorrect results are confusing but they don't hurt the metadata
> itself.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
