[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
testsuite.log.xz
Description: application/xz
0001-tar-use-SEEK_HOLE-for-hole-detection.patch
Description: Text Data
- Re: [Bug-tar] seek_hole proposal [v2],
Pavel Raiskup <=