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 majord...@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 majord...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
