Re: [Bug-tar] Detection of sparse files is broken on btrfs

[Joerg Schilling]

Paul Eggert <address@hidden> wrote:

> The implementation that you suggest requires the file system to remember 
> how much reserved space that it initially allocated to the file, even if 
> that number changes as a result of file system reorganization. This can 
> place an undue burden on more-advanced implementations. Also, it isn't 
> what most users want: users want to know how much space the file is 
> consuming now, not how much space it was consuming last week.

The amount of space a file is consuming now is the current cached state, which 
is background storage plus the current state of the cache overlay. A file that 
consumed a different amount of space last week is not what we are discussing
here....we are talking about files that do not change while something like TAR
is reading them.

So we are talking about filesystem consistency. If btrfs is able to store >= 
DEV_BSIZE data inside an existent meta data location, this would need me to
rethink whether there is a need for a different fallback algorithm for 
filesystems that do not support SEEK_HOLE. Otherwise there is a bug in btrfs 
that should be fixed.

> > If you still don't understand this, I recommend you to try to write an in 
> > kernel
> > filesystem implementation.... I did this 30 years ago.
>
> There's no need for this kind of comment. Other contributors to this 
> thread are competent, and it does not help matters for you to flash your 
> credentials.

Well, I tought that you realise that this was a hint to an icompetent other 
person that tried to use personal attacks instead of arguments.

If you care about a decent discussion, why didn't you reply to that post?

Jörg

-- 
 EMail:address@hidden                    (home) Jörg Schilling D-13353 Berlin
    address@hidden (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'