bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] seek_hole proposal [v2]


From: Pavel Raiskup
Subject: Re: [Bug-tar] seek_hole proposal [v2]
Date: Thu, 19 Nov 2015 09:10:38 +0100
User-agent: KMail/4.14.10 (Linux/4.2.5-300.fc23.x86_64; KDE/4.14.14; x86_64; ; )

On Wednesday 05 of March 2014 13:22:21 Pavel Raiskup wrote:
> On Wednesday, March 05, 2014 12:14:17 Joerg Schilling wrote:
> > Pavel Raiskup <address@hidden> wrote:
> >
> > > Note that after discussion [1] I still think that existing ST_IS_SPARSE
> > > macro is better for file-sparseness detection than using SEEK_HOLE (not
> > > worth having additional syscalls open~>seek~>close).
> > 
> > Your code is not compatible to the SEEK_HOLE interface. A file is sparse in 
> > case that pathconf()/fpathconf(f, _PC_MIN_HOLE_SIZE) return a positive 
> > number 
> > and lseek(f, (off_t)0, SEEK_HOLE) returns a number < stat.st_size.
> 
> Yes, apart from pathconf, the patch-v1 contained bug - I should react on
> hole_offset, not data_offset.  And there was yet another bug - we need to
> reposition the file offset to the beginning in this case (no FS support);
> so there needs to be done this change:
> 
>        if (offset == 0 /* first loop */
> -          && data_offset == st->stat.st_size)
> -        return false;
> +          && data_offset == 0
> +          && hole_offset == st->stat.st_size)
> +        {
> +          lseek (fd, 0, SEEK_SET);
> +          return false;
> +        }
> 
> Joerg, thanks for pointing that out.
> 
> > see "man pathconf":
> > [...]
> > 
> > In other cases, the file stil may be sparse, but the filesystem does not 
> > support SEEK_HOLE. I e.g. doubt that Linux correctly implements SEEK_HOLE
> > for NFS.
> 
> Correct, Linux's NFS returns "just" the virtual hole at the end of sparse
> file, which is now OK - we would still fallback to raw hole detection.
> Fixed patch v2 attached.

While revisiting old patches, I came here.  Sending again rebased patch.
We could make the 'seek' hole detection method optional and do 'raw' by
default (it might be wise) -- but so far there is no response from tar
maintainers -- sounds like something we don't want to have in GNU tar?

Pavel

Attachment: testsuite.log.xz
Description: application/xz

Attachment: 0001-tar-use-SEEK_HOLE-for-hole-detection.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]