remount a partition to change access permission

[Superuserlaptop]

I was not surprised that it would not work. Just trying to help and figured if you locked it down it would do the trick. It will take a better mind than mine to figure this out for you.

[gaurav-joseph]

take my word - it cannot be done
unless you edited the kernel to the distro itself
if you post the details of your linux thingy we'll look up

[lamle]

Hi all,
Thank you all so much for your support, I did not expect this much help from this great forum. For some reasons I have not got any notification email since I reopened the thread, not even in spam folder.
Maybe Irithori was right, remount a partition would not affect mmap of its file.

My directory structure:

-Home (partition1)
	- exe_folder
	- conf_folder (partition2)

The executables of threads are in exe_folder and they read configuration files from conf_folder. For some reasons the threads get suspended (~0.5s) when I remount conf_folder as rw for write operation.
I thought that the problem was because those threads could not read files in conf_folder for a short period while remounting, but I was wrong.

The actual problem was that the HOME folder (partition1) also gets affected when its conf_folder's permission is changed. Then they affect those executable. I think it has something to do with caching because it happens only in the first time I do remount with partition2.
Is it so that because partition1 detects that partition2 is in rw mode so it will prepare caching or is there other cause of this?
My Linux kernel version 2.6.23.1

[Irithori]

Unfortunately, I was unable to reproduce the described behaviour.
Also the influence of the conf partition to the home partitions seems unlikely to me.

What is the connection of executeables to conf files?
- the executeables keep the conf file filehandles open all the time
- there are constantly threads started and killed, hence the conf files are ins constant read access
(Imho, a executeable should read the conf file at start time, parse it and then close the filehandle as soon as it doesnt need it any more).

The interuption of these threads may then be related to the limited resorces of an embedded environment.
But if it only happens once.. A quick and dirty workaround could be to just do a remount while the device is booting.
So while the device is at work, you would then be able to remount without interuption.

But this is a bit of gambling.
It may pay off to strace the mount command to have more insight on what is going on.

[gaurav-joseph]

you could always stop all services remount the drive run your app which needs to write stop it and then remount ro and start all processes again

[lamle]

Hi Irithori ,

Thanks for your reply.
Because Memory Mapped files (mmap) is used, the file should always be opened for accessing. (instead of copy the content to memory and close the file for the purpose of saving memory). All threads starts once at startup.

What I tried to to have my conclusion:

- Create a new folder temp under /home.
- Mount another partition (size ~30MB) to /home/temp -> Ok
- When all the threads are running, remount the temp folder to rw -> Problem occurred.
- Problem did not occur if the mounted partition size is small.

I had a workaround same with your "quick and dirty" way, but still I am wondering what is the real cause of this problem, memory limited could be one but it is not the direct cause I think.
(I am not sure if it happens "only once")

[lamle]

you could always stop all services remount the drive run your app which needs to write stop it and then remount ro and start all processes again

Hi gaurav-joseph,

All the threads need to be kept alive all the time. And as I found out, the problem was not with reading conf files.