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.
Jan Engelhardt
--
On Tue, 29 Aug 2006 14:53:34 +0200 (MEST)
Jan Engelhardt <[email protected]> wrote:
> 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.
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.
>> 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
--
Hello everyone (yes, i?m new at this list, just correct me if i?m wrong),
I have some trouble with /proc/net/tcp and tcp6
I?m not sure if it?s a feature or a bug or maybe some cleanup of the
cache...
A long time After a connection has been established the information about
the process name and the pid itself gets lost, just a - appears.
My own network-monitoring tool uses netstat to get some information about
the network-connections. But without the pid I can't see (I could over a few
more corners but ... crap) if there are more programs at the same pid or
even which program it is (maybe an undetected Trojan or just an user with
more connections then allowed...)
Here's a link to the netstat output
http://netstat.root24.eu/netstat.php?dump=1
And to my connection-statistics (the red colored hosts/ips have no special
meaning/ just shows unresolved/new connections)
http://netstat.root24.eu/connmon.php
Normal there is a Pid and prog name in every line... since the server is
online for about a month and some connections are even so long you can see
some 'holes'
Greetings
J?rg
On Tue, 29 Aug 2006 21:21:25 +0200 (MEST)
Jan Engelhardt <[email protected]> wrote:
> >> -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.
Not all caches dropped. It'd be silly to try that - see the implementation.
Running the same command a few more times might wring a couple more dentries
and inodes out of it.
Andrew Morton <[email protected]> writes:
> 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.
>
> 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.
That's dirty area, vfat has one read-only bit only. Yes, I also think
this is strange behaviour. But, I worry app is depending on the
current behaviour, because this is pretty old behaviour.
Umm.., do someone have any strong reason? I'll make patch at this
weekend, and please test it in -mm tree for a bit long time...?
--
OGAWA Hirofumi <[email protected]>
On Wed, 30 Aug 2006 10:08:39 +0900
OGAWA Hirofumi <[email protected]> wrote:
> Andrew Morton <[email protected]> writes:
>
> > 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.
> >
> > 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.
>
> That's dirty area, vfat has one read-only bit only. Yes, I also think
> this is strange behaviour. But, I worry app is depending on the
> current behaviour, because this is pretty old behaviour.
>
> Umm.., do someone have any strong reason? I'll make patch at this
> weekend, and please test it in -mm tree for a bit long time...?
It is pretty weird that permission bits on vfat can magically change in
response to memory pressure.
But no, I'm not really advocating any changes in this area - I don't recall
any complaints (surprised) and the chances are that if we changed it
(ie: not permit the inode to accept changes which cannot be stored on disk)
then someone's app would break.
otoh, it is pretty bad behaviour...
>>
>> That's dirty area, vfat has one read-only bit only. Yes, I also think
>> this is strange behaviour. But, I worry app is depending on the
>> current behaviour, because this is pretty old behaviour.
>>
>> Umm.., do someone have any strong reason? I'll make patch at this
>> weekend, and please test it in -mm tree for a bit long time...?
>
>It is pretty weird that permission bits on vfat can magically change in
>response to memory pressure.
Well, the same happened for procfs in the past (when one was able to chmod it,
in current kernels it is forbidden.)
>But no, I'm not really advocating any changes in this area - I don't recall
>any complaints (surprised) and the chances are that if we changed it
>(ie: not permit the inode to accept changes which cannot be stored on disk)
>then someone's app would break.
>
>otoh, it is pretty bad behaviour...
It seems the best thing ATM, no?
Jan Engelhardt
--
Jan Engelhardt <[email protected]> writes:
>>>
>>> That's dirty area, vfat has one read-only bit only. Yes, I also think
>>> this is strange behaviour. But, I worry app is depending on the
>>> current behaviour, because this is pretty old behaviour.
>>>
>>> Umm.., do someone have any strong reason? I'll make patch at this
>>> weekend, and please test it in -mm tree for a bit long time...?
>>
>>It is pretty weird that permission bits on vfat can magically change in
>>response to memory pressure.
>
> Well, the same happened for procfs in the past (when one was able to chmod it,
> in current kernels it is forbidden.)
IIRC, at least 2.4 doesn't allow it, it's rather new.
> It seems the best thing ATM, no?
I also think it's good. But it wouldn't be good reason for breaking app...
--
OGAWA Hirofumi <[email protected]>