linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, George Spelvin <linux@horizon.com>,
	Zheng Liu <wenqing.lz@taobao.com>
Subject: Re: [PATCH 2/2 v2] debugfs: dump a sparse file as a new sparse file
Date: Wed, 9 Jan 2013 23:34:24 +0800	[thread overview]
Message-ID: <20130109153424.GA2945@gmail.com> (raw)
In-Reply-To: <20130109145854.GA27630@thunk.org>

On Wed, Jan 09, 2013 at 09:58:54AM -0500, Theodore Ts'o wrote:
> On Sat, Jan 05, 2013 at 12:45:22PM +0800, Zheng Liu wrote:
> > Yes, some programs call ext2fs_file_read() with a 4k or 16k fixed size
> > buffer, and ext2fs_file_read() calls ext2fs_file_read2().  But it won't
> > skip the sparse blocks because when ext2fs_file_read2() is called in
> > ext2fs_file_read(), the last argument, namely 'seek', is 0.  That means
> > that in ext2fs_file_read2() 'flags' is 0.  Thus, in load_buffer()
> > 'flags' is not equal to SEEK, and EXT2_FILE_BUF_VALID is marked.  Then
> > we return back to ext2fs_file_read2() and all data in file->buf is
> > copied.  So I think the behavior of ext2fs_file_read() doesn't be
> > changed.
> 
> You're right; I had forgotten about that part of the change.
> 
> I still am a bit concerned about the interface, because if you specify
> a pointer to seek in ext2fs_file_read2(), you have to know what the
> file system blocksize is, because if you give a count which is larger
> than a single block, the value of the returned seek and the data which
> is returned in the buffer is impossible to interpret (consider a file
> where every other 1k block is sparse, and you try to read into a 4k
> buffer).
> 
> So what I would suggest is the following as a better, more efficient
> interface.
> 
> 1) Add a new flag which can be passed into ext2_file_open() which
> requests sparse-intelligent handling.
> 
> 2) If the sparse flag is set, then ext2_file_read() will stop the read
> when it runs into the first uninitialized or sparse block.  That is,
> consider the example file which has 8k of data, a 4k uninitialized
> block, and then 12k of data after that.  If the sparse flag is passed
> to ext2_file_open(), then ext2fs_file_read(fd, buf, 16384, &got) will
> read 8k of data into buf, and return with got set to 8192.
> 
> 3) To distinguish between EOF and a sparse block, if the current file
> offset is pointed at a sparse/uninitialized block, and the sparse flag
> was passed to ext2_file_open(), then in addition to *got getting set
> 0, ext2_file_read() will also return a new error code,
> EXT2_ET_READ_HOLE_FOUND.
> 
> 4) We also extend ext2_file_llseek() to also support EXT2_SEEK_HOLE
> and EXT2_SEEK_DATA, which works like SEEK_HOLE and SEEK_DATA flags to
> llseek().  This will allow the caller to efficiently find the next
> part of the file with valid data.
> 
> What I like about this interface is that we don't need to define a new
> ext2_file_read2(), and it is also more efficient for an application
> which is interested in reading multiple blocks at a time.
> 
> What do you think?

Thanks so much for your advices.  I will try to generate the latest
patches.

Regards,
                                                - Zheng

  reply	other threads:[~2013-01-09 15:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-01 12:30 [PATCH 0/2 v2] debugfs: dump a sparse file as a new sparse file Zheng Liu
2013-01-01 12:30 ` [PATCH 1/2 v2] debugfs: fixup the hard-coded buffer length in dump_file Zheng Liu
2013-01-01 20:14   ` Theodore Ts'o
2013-01-01 12:30 ` [PATCH 2/2 v2] debugfs: dump a sparse file as a new sparse file Zheng Liu
2013-01-01 20:38   ` Theodore Ts'o
2013-01-04  4:05     ` Zheng Liu
2013-01-04 19:37       ` Theodore Ts'o
2013-01-05  4:45         ` Zheng Liu
2013-01-09 14:58           ` Theodore Ts'o
2013-01-09 15:34             ` Zheng Liu [this message]
2013-01-10  0:42             ` George Spelvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130109153424.GA2945@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=tytso@mit.edu \
    --cc=wenqing.lz@taobao.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).