[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4F99E476.5020106@redhat.com>
Date: Thu, 26 Apr 2012 19:12:38 -0500
From: Eric Sandeen <sandeen@...hat.com>
To: Andreas Dilger <aedilger@...il.com>
CC: ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH, RFC2] vfs: teach llseek about custom EOF values
On 4/26/12 6:42 PM, Andreas Dilger wrote:
...
>> /*
>> + * ext4_dir_llseek() uses generic_file_llseek() routines.
>> + * This handles both non-htree and htree directories, where the "offset"
>> + * is in terms of the filename hash value instead of the byte offset.
>> + *
>> + * For htree/dx dirs, the max offset and SEEK_END are both at
>> + * ext4_get_htree_eof.
>> *
>> * NOTE: offsets obtained *before* ext4_set_inode_flag(dir, EXT4_INODE_INDEX)
>> * will be invalid once the directory was converted into a dx directory
>> @@ -322,64 +325,23 @@ static inline loff_t ext4_get_htree_eof(struct file *filp)
>> loff_t ext4_dir_llseek(struct file *file, loff_t offset, int origin)
>> {
>> struct inode *inode = file->f_mapping->host;
>> int dx_dir = is_dx_dir(inode);
>
> [Note: I trimmed the deleted lines, since it made the patch unreadable]
>
> I like this patch, since it is quite clean and readable, and we aren't
> reimplementing the generic_file_llseek code.
>
> The reasons why I prefer the variant that SEEK_END returns a hash value
> are twofold. Firstly, it is just more consistent that if SEEK_CUR and
> SEEK_SET are using hash-offset values that SEEN_END also does the same.
>
> Secondly, as for usefulness, I'm thinking of the case where there is
> a very large directory, and some application wants to process it in
> parallel. It can call SEEK_END to get the "end" of the directory,
> regardless of whether this is a hash-offset directory or a file-offset
> directory (assuming SEEK_END is implemented correctly as in this patch),
> and then for each thread it can seek and process a part of the single
> directory in parallel (for each thread n of N):
>
> loff_t end = llseek(dirfd, 0, SEEK_END);
>
> thread_off = llseek(dirfd, n * (end / N), SEEK_SET);
>
> I think this is a useful programming model, and that parallel processing
> of small directories has not been an issue in the past is no reason not
> to allow this in the future. The application can still use "stat()" to
> find the actual file size, and it makes sense that the "seek space" for
> a file be consistent is just good programming practise.
>
> Cheers, Andreas
Ok, thanks. Maybe I'll try to get it upstream... also:
>> +generic_file_llseek_size(struct file *file, loff_t offset, int origin,
>> + loff_t maxsize)
>> +{
>> + return generic_file_llseek_size(file, offset, origin, maxsize, 0);
>> +}
>> EXPORT_SYMBOL(generic_file_llseek_size);
Oops, realized I must have forgotten a patch refresh, this should be calling _size_eof. Still, you get the idea. I'll clean it up & try it upstream.
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists