Paul Eggert <egg...@cs.ucla.edu> wrote:
> On 01/08/2018 08:06 AM, Joerg Schilling wrote:
> > blkcnt_t st_blocks Number of blocks allocated for this object.
> >
> > I hope I do not need to explain the term "allocated".
>
> I'm afraid that you do need to explain "allocated". Suppose, for
> example, two files are clones: they have different inode numbers and are
> different files from the POSIX point of view, but they have the same
> contents and only one copy exists at the lower level. How many blocks
> are "allocated" for each file?
POSIX does not explain what happens with several filesystems.
For this reason, I cannot see any reason why deduplication between different
filesystems that share a common dataset should be alllowed to be visible at
user level.
Also note that "du" may report more blocks than you expect in case it does not
have the ability to honor hard linked files.
The most important fact however is that allocating spade happens before you
copy data into that space. A file with more data than what can be hold in the
inode thus must have st_blocks > 0.
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
