Hello,
I would like to remove an executable from the file-system while it is
running and
get all the blocks back immediately, not after the end of the program.
Is this possible ?
From what I understand, the inode is not released until the program
ends. Do all the
file-systems behave the same way ?
Thank you for your help.
Cyrille Beraud wrote:
>
> Hello,
> I would like to remove an executable from the file-system while it is
> running and
> get all the blocks back immediately, not after the end of the program.
> Is this possible ?
> From what I understand, the inode is not released until the program
> ends. Do all the
> file-systems behave the same way ?
>
> Thank you for your help.
It is not possible to reclaim the disk space until the program exits.
This is because of demand paging of executables. The file must be kept
around to handle possible future page faults, otherwise the program
would crash if it called code that hadn't been loaded yet or was
discarded due to memory pressure. This is true of all filesystems.
--
Brian Gerst
On 5 Dec 01 at 11:00, Cyrille Beraud wrote:
> I would like to remove an executable from the file-system while it is
> running and
> get all the blocks back immediately, not after the end of the program.
> Is this possible ?
No. Binary runs from these blocks. Maybe you can force it to run from
swap by modifying these pages through ptrace interface, but it is
not supported. Just kill the app if you need these blocks.
> From what I understand, the inode is not released until the program
> ends. Do all the file-systems behave the same way ?
No. Some will refuse to unlink running app (or another opened file).
Some will unlink it immediately, and app then dies when it needs
page-in something. Some works as POSIX mandates.
Best regards,
Petr Vandrovec
[email protected]
On Wed, Dec 05, 2001 at 05:15:52PM +0000, Petr Vandrovec wrote:
> On 5 Dec 01 at 11:00, Cyrille Beraud wrote:
>
> > I would like to remove an executable from the file-system while it is
> > running and
> > get all the blocks back immediately, not after the end of the program.
> > Is this possible ?
>
> No. Binary runs from these blocks. Maybe you can force it to run from
> swap by modifying these pages through ptrace interface, but it is
> not supported. Just kill the app if you need these blocks.
>
> > From what I understand, the inode is not released until the program
> > ends. Do all the file-systems behave the same way ?
>
> No. Some will refuse to unlink running app (or another opened file).
> Some will unlink it immediately, and app then dies when it needs
> page-in something. Some works as POSIX mandates.
>
POSIX behaviour would be in ext[23], reiserfs, xfs, (and probably ffs,
ntfs). Can someone verify which FSes have what behaviour?
I'd guess that vfat (fat16/28--err, 32), nfs, and hfs would delete
immediately.
mf
Brian Gerst wrote:
>
> Cyrille Beraud wrote:
> >
> > Hello,
> > I would like to remove an executable from the file-system while it is
> > running and
> > get all the blocks back immediately, not after the end of the program.
> > Is this possible ?
> > From what I understand, the inode is not released until the program
> > ends. Do all the
> > file-systems behave the same way ?
> >
> > Thank you for your help.
>
> It is not possible to reclaim the disk space until the program exits.
> This is because of demand paging of executables. The file must be kept
> around to handle possible future page faults, otherwise the program
> would crash if it called code that hadn't been loaded yet or was
> discarded due to memory pressure. This is true of all filesystems.
Couldn't you use mlockall() to ensure that demand paging is not a factor? Then
you should be able to free up the disk space since the actual application is
guaranteed to be in ram.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On 5 Dec 01 at 11:32, Mike Fedyk wrote:
> > No. Some will refuse to unlink running app (or another opened file).
> > Some will unlink it immediately, and app then dies when it needs
> > page-in something. Some works as POSIX mandates.
> >
>
> POSIX behaviour would be in ext[23], reiserfs, xfs, (and probably ffs,
> ntfs). Can someone verify which FSes have what behaviour?
>
> I'd guess that vfat (fat16/28--err, 32), nfs, and hfs would delete
> immediately.
ncpfs (and afaik smbfs) will refuse to delete file. For local filesystems
there is no excuse to not support POSIX semantic on unlink if they do not
store data together with filename.
Petr Vandrovec
[email protected]
On 12/05/2001 15:00 -0500, Christopher Friesen wrote:
>> Couldn't you use mlockall() to ensure that demand paging is not a factor? Then
>> you should be able to free up the disk space since the actual application is
>> guaranteed to be in ram.
>>
mlockall() only locks those pages that are **currently** paged
in, or optionally those that will be paged in in the future.
Unless you have a way to make sure that all pages of the
binary are actually in memory before you call mlockall(),
this gains you nothing.
--
[email protected]
[email protected] said:
> mlockall() only locks those pages that are **currently** paged in, or
> optionally those that will be paged in in the future. Unless you have
> a way to make sure that all pages of the binary are actually in memory
> before you call mlockall(), this gains you nothing.
No, mlockall will page in the entire process before returning if you ask it to.
See this snippet in mlock_fixup:
if (newflags & VM_LOCKED) {
pages = -pages;
make_pages_present(start, end);
}
VM_LOCKED comes in through the mlockall system call.
Jeff
On Wed, Dec 05, 2001 at 07:25, Jeff Dike wrote:
> [email protected] said:
> > mlockall() only locks those pages that are **currently** paged in, or
> > optionally those that will be paged in in the future. Unless you have
> > a way to make sure that all pages of the binary are actually in memory
> > before you call mlockall(), this gains you nothing.
>
> No, mlockall will page in the entire process before returning if you ask it to.
>
> See this snippet in mlock_fixup:
>
> if (newflags & VM_LOCKED) {
> pages = -pages;
> make_pages_present(start, end);
> }
>
> VM_LOCKED comes in through the mlockall system call.
>
> Jeff
Well, according to the man page, mister Walberg is right. How can I
force mlockall to page in the entire process ? And if it is possible,
I guess it won't resolve my problem since it is the filesystem which
refuses to release the blocks, right ?
To be more precise, here is my situation: the executable file is
located on a ramfs filesystem. Once it is started, I would like to get
the space back so that the RAM can be used. Is there a clean solution ?
P.S: on behalf of Cyrille (who made the first post), I would like to
thank you for your answers, it is greatly appreciated.
P.P.S: is it required to include the people involved in the thread in
the Cc: field ? I have looked in the mailing list FAQ and have not
found the reason.
--
Eric-Olivier Lamey