Re: Drop cache has no effect?

[Jan Engelhardt]

>> Hello,
>> 
>> recently I picked up knowledge of /proc/sys/vm/drop_caches 
>> (http://lkml.org/lkml/2006/8/4/95)
>> 
>> It does not always work right away:
>> 
>> (/U is a vfat, that is, permissions are back to 755 as soon as the caches 
>> are gone)
>> 14:51 gwdg-wb04A:/U # chmod 644 *
>> 14:51 gwdg-wb04A:/U # sync
>> 14:51 gwdg-wb04A:/U # echo 2 >/proc/sys/vm/drop_caches 
>> 14:51 gwdg-wb04A:/U # l
>> total 50713
>> drwxr-xr-x   3 jengelh users     2048 2006-08-29 14:48 .
>> drwxr-xr-x  22 root    root      4096 2006-08-25 14:00 ..
>> drw-r--r--   2 jengelh users     2048 2006-08-29 13:55 as
>> -rw-r--r--   1 jengelh users 13806629 2006-08-29 14:00 all-20060611.tar.bz2
>> -rw-r--r--   1 jengelh users 37816633 2006-07-28 19:25 
>> inkscape-0.44-2.guru.suse101.i686.rpm
>> -rw-r--r--   1 jengelh users   297243 2006-08-15 01:13 
>> vmware-any-any-update104.tar.gz
>> 
>> Remains 644.
>
>That would be a vfat problem - the changed permission bits weren't written
>back to disk, so when you re-read them from disk (or, more likely, from
>blockdev pagecache) they came back with the original values.

Yes, that's _intended_.

Fact:
If you chmod 644 some files on vfat, then unmount and mount it again, they show
up as 755 again. That is ok.

Observation:
Dropping the cache does not imply the 644->755 change observed on unmount.

Conclusion:
Caches not dropped.


>Does vfat even have the ability to store the seven bits?  Don't think so? 
>If not, permitting the user to change them in icache but not being to write
>them out to permanent store seems rather bad behaviour.

It is, I think, for compat reasons. Who knows how many apps don't expect chmod
to fail when they know you are the owner.



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