lkml.org 
[lkml]   [2012]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 11/16] f2fs: add inode operations for special inodes
From
Date

On Oct 14, 2012, at 11:09 AM, Jaegeuk Kim wrote:

> 2012-10-14 (일), 02:21 +0400, Vyacheslav Dubeyko:
>> On Oct 14, 2012, at 12:52 AM, Arnd Bergmann wrote:
>>
>>> On Friday 05 October 2012, 김재극 wrote:
>>>> +const char *media_ext_lists[] = {
>>>> + "jpg",
>>>> + "gif",
>>>> + "png",
>>>> + "avi",
>>>> + "divx",
>>>> + "mp4",
>>>> + "mp3",
>>>> ...
>>>
>>>> + * Set multimedia files as cold files for hot/cold data separation
>>>> + */
>>>> +static inline void set_cold_file(struct inode *inode, const unsigned char *name)
>>>> +{
>>>> + const char **extlist = media_ext_lists;
>>>> +
>>>> + while (*extlist) {
>>>> + if (!is_multimedia_file(name, *extlist)) {
>>>> + F2FS_I(inode)->is_cold = 1;
>>>> + break;
>>>> + }
>>>> + extlist++;
>>>> + }
>>>> +}
>>>
>>> This is a very clever way of categorizing files by their name, but I wonder if hardcoding
>>> the list of file name extensions at in the kernel source is the best strategy. Generally
>>> I would consider this to be a policy that should be configurable by the user.
>>>
>>> Unfortunately I can't think of a good interface to configure this, but maybe someone
>>> else has a useful idea. Maybe the list can be stored in the superblock and get written
>>> at mkfs time from the same defaults, but with the option of overriding it using
>>> a debugfs tool.
>>>
>>
>> By the way, how about extended attributes? It is possible to save in extended attribute a hint about file's content nature during creation operation or later. Moreover, extended attribute gives possibility to change hint after renaming operation, for example.
>>
>
> I think xattr is not a proper way to communicate between file system and
> users.

I don't understand why you think that xattr is not proper way. Extended attributes are the way of adding some additional properties to filesystem object, from my point of view.

> How about fadvise()?
>

The fadvise() is a good suggestion. But, as I can understand, such solution requires using fadvise() during application implementation. So, from one point of view, it exists many applications that doesn't use fadvise() and, from another point of view, developers change style of coding not so easy.

Extended attributes are more flexible way, from my point of view. The xattr gives possibility to make hint to filesystem at any time and without any dependencies with application's functional opportunities. Documented way of using such extended attributes gives to user flexible way of manipulation of filesystem behavior (but I remember that you don't believe in an user :-)).

So, I think that fadvise() and extended attributes can be complementary solutions.

Anyway, hardcoding or saving in filesystem list of file extensions is a nasty way. It can be not safe or hardly understandable by users the way of reconfiguration filesystem by means of tunefs or debugfs with the purpose of file extensions addition in such "black-box" as TV or smartphones, from my point of view.

With the best regards,
Vyacheslav Dubeyko.

>> With the best regards,
>> Vyacheslav Dubeyko.
>>
>>> Arnd
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Jaegeuk Kim
> Samsung
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-10-14 14:41    [W:0.099 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site