On Thu, 29 Nov 2012, Jaegeuk Hanse wrote:
> On Wed, Nov 28, 2012 at 05:22:03PM -0800, Hugh Dickins wrote:
> >Revert 3.5's f21f8062201f ("tmpfs: revert SEEK_DATA and SEEK_HOLE")
> >to reinstate 4fb5ef089b28 ("tmpfs: support SEEK_DATA and SEEK_HOLE"),
> >with the intervening additional arg to generic_file_llseek_size().
> >
> >In 3.8, ext4 is expected to join btrfs, ocfs2 and xfs with proper
> >SEEK_DATA and SEEK_HOLE support; and a good case has now been made
> >for it on tmpfs, so let's join the party.
> >
>
> Hi Hugh,
>
> IIUC, several months ago you revert the patch. You said,
>
> "I don't know who actually uses SEEK_DATA or SEEK_HOLE, and whether it
> would be of any use to them on tmpfs. This code adds 92 lines and 752
> bytes on x86_64 - is that bloat or worthwhile?"
YUC.
>
> But this time in which scenario will use it?
I was not very convinced by the grep argument from Jim and Paul:
that seemed to be grep holding on to a no-arbitrary-limits dogma,
at the expense of its users, causing an absurd line-length issue,
which use of SEEK_DATA happens to avoid in some cases.
The cp of sparse files from Jeff and Dave was more convincing;
but I still didn't see why little old tmpfs needed to be ahead
of the pack.
But at LinuxCon/Plumbers in San Diego in August, a more convincing
case was made: I was hoping you would not ask, because I did not take
notes, and cannot pass on the details - was it rpm building on tmpfs?
I was convinced enough to promise support on tmpfs when support on
ext4 goes in.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
