Fix SWSUSP & !SWAP
Hi!
Swsusp without swap makes no sense, but leads to compilation failure. This fixes it. Please apply,
Pavel
arch/i386/Kconfig +1 -1
@@ -798,7 +798,7 @@ config SOFTWARE_SUSPEND bool "Software Suspend (EXPERIMENTAL)" - depends on EXPERIMENTAL && PM + depends on EXPERIMENTAL && PM && SWAP ---help--- Enable the possibilty of suspendig machine. It doesn't need APM. You may suspend your machine by 'swsusp' or 'shutdown -z <time>'
arch/x86_64/Kconfig +1 -1
@@ -286,7 +286,7 @@ config SOFTWARE_SUSPEND bool "Software Suspend (EXPERIMENTAL)" - depends on EXPERIMENTAL && PM + depends on EXPERIMENTAL && PM && SWAP ---help--- Enable the possibilty of suspending the machine. It doesn't need APM. You may suspend your machine by 'swsusp' or 'shutdown -z <time>'
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 2 lines · Pavel Machek
Swsusp without swap makes no sense, but leads to compilation failure. This fixes it. Please apply,
Just wondering, what about MMU-less machines?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi!
Quoted 4 lines
Quoted 2 lines
Swsusp without swap makes no sense, but leads to compilation failure. This fixes it. Please apply,
Just wondering, what about MMU-less machines?
Ugh... Currently: no we can't do that. We are happy to suspend/resume on i386 ;-).
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Hi All,
Just a quick question:
As I know, swsusp is for hybernation (S4), right? The memory content will be written to the swap partition. What happens if the swap space is already used from programs? Abort? Or do I have to reserve swap space which never has to be used from programs?
Thank you!
Marc
Quoted 10 lines · On Wed, 23 Apr 2003 16:47:05 +0200 Pavel Machek <[email protected]> wrote:
Hi!
Quoted 4 lines
Quoted 2 lines
Swsusp without swap makes no sense, but leads to compilation failure. This fixes it. Please apply,
Just wondering, what about MMU-less machines?
Ugh... Currently: no we can't do that. We are happy to suspend/resume on i386 ;-).
Pavel
Swsusp will use the portion of your swap partition that is unused when you start to suspend. The version currently in the 2.5 tree frees most of your memory before suspending, and so doesn't need that much swap at all. The version that I'm working on merging only frees memory if it is necessary to fit the image in the available swap or to have enough memory to be able to save the image. Thus, you need a lot more swap for my version. (eg. I have 640MB ram on my laptop and a ~700MB swap partition).
Hope this helps.
Regards,
Nigel
Quoted 21 lines · On Thu, 2003-04-24 at 03:56, [email protected] wrote:
Hi All,
Just a quick question:
As I know, swsusp is for hybernation (S4), right? The memory content will be written to the swap partition. What happens if the swap space is already used from programs? Abort? Or do I have to reserve swap space which never has to be used from programs?
Thank you!
Marc
Signature · 6 lines
Nigel Cunningham 495 St Georges Road South, Hastings 4201, New Zealand Be diligent to present yourself approved to God as a workman who does not need to be ashamed, handling accurately the word of truth. -- 2 Timothy 2:14, NASB.
Hi Nigel, Hi All
Quoted 9 lines · On Thu, 24 Apr 2003 07:41:11 +1200 Nigel Cunningham <[email protected]>…
Swsusp will use the portion of your swap partition that is unused when you start to suspend. The version currently in the 2.5 tree frees most of your memory before suspending, and so doesn't need that much swap at all. The version that I'm working on merging only frees memory if it is necessary to fit the image in the available swap or to have enough memory to be able to save the image. Thus, you need a lot more swap for my version. (eg. I have 640MB ram on my laptop and a ~700MB swap partition).
Ok! I see the advantages / disadvantages of each version. But what happens if the memory AND swap space are full and nothing can't be freed? When I watch the memory and swap consumption on my laptop, I think it's the most time the case...
Another question:
Is it a big problem to save the memory in a separate file on the file system, and save somewhere the pointer to it (as example in swap. Also we could set a flag in swap so that we now that the last shutdown was a hybernation). One Problem will be, that we don't know the filesystem type on resume...(We could save the module in swap...) All that is just theoretical. It's only a idea.
Thank you for your statements.
greets
Marc
Quoted 4 lines · Marc Giger
Ok! I see the advantages / disadvantages of each version. But what happens if the memory AND swap space are full and nothing can't be freed? When I watch the memory and swap consumption on my laptop, I think it's the most time the case...
If you're getting yourself in that situation, you should be increasing your swap space (and memory if possible) anyway.
Quoted 7 lines
Another question:
Is it a big problem to save the memory in a separate file on the file system, and save somewhere the pointer to it (as example in swap. Also we could set a flag in swap so that we now that the last shutdown was a hybernation). One Problem will be, that we don't know the filesystem type on resume...(We could save the module in swap...)
All that is just theoretical. It's only a idea.
I guess the simplest answer is would it be worth the pain? Since disk space is cheap, it just requires a little forethought when installing Linux, to ensure enough swap is allocated. I certainly understand that using a file rather than swap makes adjusting the amount of space available easier, but as you rightly acknowledge, it does complicate things a fair bit more.
Regards,
Nigel
Signature · 6 lines
Nigel Cunningham 495 St Georges Road South, Hastings 4201, New Zealand Be diligent to present yourself approved to God as a workman who does not need to be ashamed, handling accurately the word of truth. -- 2 Timothy 2:14, NASB.
Quoted 17 lines · Marc Giger
Quoted 4 lines
Ok! I see the advantages / disadvantages of each version. But what happens if the memory AND swap space are full and nothing can't be freed? When I watch the memory and swap consumption on my laptop, I think it's the most time the case...
If you're getting yourself in that situation, you should be increasing your swap space (and memory if possible) anyway.
Quoted 7 lines
Another question:
Is it a big problem to save the memory in a separate file on the file system, and save somewhere the pointer to it (as example in swap. Also we could set a flag in swap so that we now that the last shutdown was a hybernation). One Problem will be, that we don't know the filesystem type on resume...(We could save the module in swap...)
All that is just theoretical. It's only a idea.
Quoted 6 lines
I guess the simplest answer is would it be worth the pain? Since disk space is cheap, it just requires a little forethought when installing Linux, to ensure enough swap is allocated. I certainly understand that using a file rather than swap makes adjusting the amount of space available easier, but as you rightly acknowledge, it does complicate things a fair bit more.
Can't you just create a pre-reserved separate swsusp area on disk the size
of RAM (maybe a partition rather than a file to make things easier), and
then you know you're safe (basically what Marc was suggesting, except pre-allocated)? Or does that make me the prince of all evil? ;-)
However much swap space you allocate, it can always all be used, so that seems futile ...
M.
Hi!
Quoted 23 lines
Quoted 16 lines
Quoted 4 lines
Ok! I see the advantages / disadvantages of each version. But what happens if the memory AND swap space are full and nothing can't be freed? When I watch the memory and swap consumption on my laptop, I think it's the most time the case...
If you're getting yourself in that situation, you should be increasing your swap space (and memory if possible) anyway.
Quoted 7 lines
Another question:
Is it a big problem to save the memory in a separate file on the file system, and save somewhere the pointer to it (as example in swap. Also we could set a flag in swap so that we now that the last shutdown was a hybernation). One Problem will be, that we don't know the filesystem type on resume...(We could save the module in swap...)
All that is just theoretical. It's only a idea.Quoted 6 lines
I guess the simplest answer is would it be worth the pain? Since disk space is cheap, it just requires a little forethought when installing Linux, to ensure enough swap is allocated. I certainly understand that using a file rather than swap makes adjusting the amount of space available easier, but as you rightly acknowledge, it does complicate things a fair bit more.
Quoted 6 lines
Can't you just create a pre-reserved separate swsusp area on disk the size
of RAM (maybe a partition rather than a file to make things easier), and
then you know you're safe (basically what Marc was suggesting, except pre-allocated)? Or does that make me the prince of all evil? ;-)However much swap space you allocate, it can always all be used, so that seems futile ...
Well, but if all the swaps gets used, you go OOM and randomly kill processes. That means that machines have way more swap than they need.
If you really want to "solve" it reliably, you can always
swapon /dev/hdfoo666
where hdfoo666 is as big as ram, just before starting swsusp. We could even make swapon part of swsusp where its locked to kill races.
But I believe its not needed. Problem just is not there in practise.
Pavel
Signature · 2 lines
Horseback riding is like software... ...vgf orggre jura vgf serr.
Quoted 11 lines
Well, but if all the swaps gets used, you go OOM and randomly kill processes. That means that machines have way more swap than they need.
If you really want to "solve" it reliably, you can always
swapon
/dev/hdfoo666where hdfoo666 is as big as ram, just before starting swsusp. We could even make swapon part of swsusp where its locked to kill races.
But I believe its not needed. Problem just is not there in practise.
OK, well suppose RAM is full, and swap is almost full (less than used RAM left). System is still running fine, no OOM. But suspend can't work, AFAICS.
Saving a separate area to save RAM into seems like the only deterministic method to me.
M.
Quoted 5 lines · Pavel Machek
If you really want to "solve" it reliably, you can always
swapon
/dev/hdfoo666
Seems that using a swapfile instead of a swapdev would fix that neatly.
But iirc, suspend doesn't work with swapfiles. Is that correct? If so, what has to be done to get it working?
Quoted 10 lines · Andrew Morton
Quoted 4 lines · Pavel Machek
If you really want to "solve" it reliably, you can always
swapon
/dev/hdfoo666Seems that using a swapfile instead of a swapdev would fix that neatly.
But iirc, suspend doesn't work with swapfiles. Is that correct? If so, what has to be done to get it working?
I'm curious. What does a swapfile solve that a swapdev does not? Either way you need to prealloc the case (either have a chunky file in a partition or a partition set aside) or you need to keep enough room avail to fit the file when it's needed.
Signature · 6 lines
Martin's distress was in contrast to the bitter satisfaction of some of his fellow marines as they surveyed the scene. "The Iraqis are sick people and we are the chemotherapy," said Corporal Ryan Dupre. "I am starting to hate this country. Wait till I get hold of a friggin' Iraqi. No, I won't get hold of one. I'll just kill him." - http://www.informationclearinghouse.info/article2479.htm
Quoted 4 lines · CaT
I'm curious. What does a swapfile solve that a swapdev does not? Either way you need to prealloc the case (either have a chunky file in a partition or a partition set aside) or you need to keep enough room avail to fit the file when it's needed.
Nothing but further bloat in swsusp :> With a swapfile, we need to know the location of the file (and be able to find it again when it changes, and know how to find the next block in the file system - it might be fragmented). The simplest solution is to keep using the current method and create a separate swap partition if you really feel you need to, only turning it on before swap and turning if off afterwards. As Pavel said, code could be added to get swsusp to do it itself.
Regards,
Nigel
Signature · 6 lines
Nigel Cunningham 495 St Georges Road South, Hastings 4201, New Zealand Be diligent to present yourself approved to God as a workman who does not need to be ashamed, handling accurately the word of truth. -- 2 Timothy 2:14, NASB.
On Thu, 24 Apr 2003 12:16:48 +1200 Nigel Cunningham <[email protected]> wrote:
| On Thu, 2003-04-24 at 12:17, CaT wrote: | > I'm curious. What does a swapfile solve that a swapdev does not? Either | > way you need to prealloc the case (either have a chunky file in a | > partition or a partition set aside) or you need to keep enough room | > avail to fit the file when it's needed. | | Nothing but further bloat in swsusp :> With a swapfile, we need to know | the location of the file (and be able to find it again when it changes, | and know how to find the next block in the file system - it might be | fragmented). The simplest solution is to keep using the current method | and create a separate swap partition if you really feel you need to, | only turning it on before swap and turning if off afterwards. As Pavel | said, code could be added to get swsusp to do it itself.
That may be simple for you, but for lots of users, adding a partition (to a ususally full disk drive) isn't simple. It means backups, shrink a filesystem, shrink a partition, add a partition, and run
mkswap on it. Yes, the latter 2 are simple, but the former ones
are not.
Oh, and then just start over and install everything from backups. :(
--
~Randy
Quoted 5 lines · Randy.Dunlap
| fragmented). The simplest solution is to keep using the current method | and create a separate swap partition if you really feel you need to, | only turning it on before swap and turning if off afterwards. As Pavel | said, code could be added to get swsusp to do it itself.
Quoted 7 lines
That may be simple for you, but for lots of users, adding a partition (to a ususally full disk drive) isn't simple. It means backups, shrink a filesystem, shrink a partition, add a partition, and run
mkswap on it. Yes, the latter 2 are simple, but the former ones
are not.Oh, and then just start over and install everything from backups. :(
parted should help with this. Dunno if it can move the start of a partition yet but you can move the end down and put in your suspend partition in the space you just made.
Signature · 6 lines
Martin's distress was in contrast to the bitter satisfaction of some of his fellow marines as they surveyed the scene. "The Iraqis are sick people and we are the chemotherapy," said Corporal Ryan Dupre. "I am starting to hate this country. Wait till I get hold of a friggin' Iraqi. No, I won't get hold of one. I'll just kill him." - http://www.informationclearinghouse.info/article2479.htm
Quoted 6 lines · Randy.Dunlap
That may be simple for you, but for lots of users, adding a partition (to a ususally full disk drive) isn't simple. It means backups, shrink a filesystem, shrink a partition, add a partition, and run
mkswap on it. Yes, the latter 2 are simple, but the former ones
are not.
Yeah. swsusp is pretty much the only reason why you would want to have a swap partition at all in a 2.5/2.6 kernel.
Quoted 10 lines · Andrew Morton
Quoted 6 lines · Randy.Dunlap
That may be simple for you, but for lots of users, adding a partition (to a ususally full disk drive) isn't simple. It means backups, shrink a filesystem, shrink a partition, add a partition, and run
mkswap on it. Yes, the latter 2 are simple, but the former ones
are not.Yeah. swsusp is pretty much the only reason why you would want to have a swap partition at all in a 2.5/2.6 kernel.
Is there really no difference any longer in terms of speed?
Signature · 6 lines
Martin's distress was in contrast to the bitter satisfaction of some of his fellow marines as they surveyed the scene. "The Iraqis are sick people and we are the chemotherapy," said Corporal Ryan Dupre. "I am starting to hate this country. Wait till I get hold of a friggin' Iraqi. No, I won't get hold of one. I'll just kill him." - http://www.informationclearinghouse.info/article2479.htm
Quoted 10 lines · CaT
Quoted 8 lines · Andrew Morton
Quoted 6 lines · Randy.Dunlap
That may be simple for you, but for lots of users, adding a partition (to a ususally full disk drive) isn't simple. It means backups, shrink a filesystem, shrink a partition, add a partition, and run
mkswap on it. Yes, the latter 2 are simple, but the former ones
are not.
Quoted 4 lines
Quoted 2 lines
Yeah. swsusp is pretty much the only reason why you would want to have a swap partition at all in a 2.5/2.6 kernel.
Is there really no difference any longer in terms of speed?
Nope. Not unless the swapfile which you created is splattered all over the disk, in whcih case you already have serious problems with that filesystem.
There will some performance differences with resume, because it is doing page-at-a-time synchronous IO. The device-level caching should make that acceptable though.
Quoted 8 lines
Quoted 5 lines
That may be simple for you, but for lots of users, adding a partition (to a ususally full disk drive) isn't simple. It means backups, shrink a filesystem, shrink a partition, add a partition, and run
mkswap on it. Yes, the latter 2 are simple, but the former ones
are not.Yeah. swsusp is pretty much the only reason why you would want to have a swap partition at all in a 2.5/2.6 kernel.
A lot of users still follow the 'swap space twice the size of physical RAM' rule of thumb.
Now that physical RAM sizes have increased by an order of magnitude since that advice was given, there are a lot of systems with far more swap than they need, which provides the solution to our problem - if there is a single swap partition which is twice the size of physical RAM, just split it in to SWAP and SWSUSP slices, (not separate partitions, slices in the same way BSD subdivides a partition).
2.4 kernels will see a big swap area, and use all of it as swap, 2.5 kernels will see a smaller swap area, (equal to physical RAM size, and therefore sufficient in a lot of cases), and a SWSUSP area the same size as physical RAM.
John.
Quoted 11 lines · Nigel Cunningham
Quoted 4 lines · CaT
I'm curious. What does a swapfile solve that a swapdev does not? Either way you need to prealloc the case (either have a chunky file in a partition or a partition set aside) or you need to keep enough room avail to fit the file when it's needed.
Nothing but further bloat in swsusp :> With a swapfile, we need to know the location of the file (and be able to find it again when it changes, and know how to find the next block in the file system - it might be fragmented).
That's because swsusp is using the mm/page_io.c functions for suspend, but is using the fs/buffer.c functions direct to the blockdev for resume.
If you can use the swapper_space a_ops for both suspend and resume (say:
"cleanup") then it will just work.
Hi!
Quoted 10 lines
Quoted 9 lines
Quoted 4 lines
I'm curious. What does a swapfile solve that a swapdev does not? Either way you need to prealloc the case (either have a chunky file in a partition or a partition set aside) or you need to keep enough room avail to fit the file when it's needed.
Nothing but further bloat in swsusp :> With a swapfile, we need to know the location of the file (and be able to find it again when it changes, and know how to find the next block in the file system - it might be fragmented).
Quoted 5 lines
That's because swsusp is using the
mm/page_io.cfunctions for suspend, but is using thefs/buffer.cfunctions direct to the blockdev for resume.If you can use the
swapper_spacea_opsfor both suspend and resume (say:
"cleanup") then it will just work.
No, ext3 will be "unclean" during resume (you can't really unmount it during suspend!) and r-o mounting of ext3 will replay journal and cause data corruption.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 4 lines · Pavel Machek
No, ext3 will be "unclean" during resume (you can't really unmount it during suspend!) and r-o mounting of ext3 will replay journal and cause data corruption.
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
3) restart, journal replay
4) resume reads pages from disk.
Where did the corruption happen?
Please bear in mind that I don't really know how swsusp works, so tell it to me in nice simple steps.
Hi!
Quoted 6 lines
Quoted 3 lines
No, ext3 will be "unclean" during resume (you can't really unmount it during suspend!) and r-o mounting of ext3 will replay journal and cause data corruption.
Sorry, I still don't get it. Go through the steps for me:
Quoted 7 lines
1) suspend writes pages to disk
2) machine is shutdown
3) restart, journal replay
4) resume reads pages from disk.
And now you have kernel which expects data still in journal (that was state before suspend), but reality on disk is quite different (journal was replayed). Data corruption.
Simple enough steps?
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 13 lines · Pavel Machek
Hi!
Quoted 10 lines
Quoted 3 lines
No, ext3 will be "unclean" during resume (you can't really unmount it during suspend!) and r-o mounting of ext3 will replay journal and cause data corruption.
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
Quoted 7 lines
Quoted 3 lines
3) restart, journal replay
4) resume reads pages from disk.
And now you have kernel which expects data still in journal (that was state before suspend), but reality on disk is quite different (journal was replayed). Data corruption.
swapfiles are not journalled - the swap a_ops write direct to the swapfile's blocks with submit_bio(). Journal replay wouldn't touch the swapfile.
I can see that locating the swapfile for the resume-time swapon could be a problem, but the corruption thing still escapes me.
Quoted 7 lines · Andrew Morton
Quoted 7 lines
Quoted 7 lines
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
3) restart, journal replay
Corruption comes here. The journal reply tidies things up that shouldn't be tidied up. They shouldn't be tidied up because once we reload the image, things should be in the same state as prior to suspend. If replay frees a block (thinking it wasn't properly linked or something similar), it introduces corruption.
Quoted 5 lines
swapfiles are not journalled - the swap
a_opswrite direct to the swapfile's blocks withsubmit_bio(). Journal replay wouldn't touch the swapfile.I can see that locating the swapfile for the resume-time swapon could be a problem, but the corruption thing still escapes me.
Regards,
Nigel
Signature · 6 lines
Nigel Cunningham 495 St Georges Road South, Hastings 4201, New Zealand Be diligent to present yourself approved to God as a workman who does not need to be ashamed, handling accurately the word of truth. -- 2 Timothy 2:14, NASB.
Quoted 8 lines · Nigel Cunningham
Quoted 6 lines · Andrew Morton
Quoted 6 lines
Quoted 6 lines
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
3) restart, journal replay
Corruption comes here. The journal reply tidies things up that shouldn't be tidied up. They shouldn't be tidied up because once we reload the image, things should be in the same state as prior to suspend. If replay frees a block (thinking it wasn't properly linked or something similar), it introduces corruption.
No, this will not happen. All swapfile blocks must be allocated by swapon time. It is just a chunk of disk and replay will not touch it.
That's for ext3, and no other filesystems journal data anyway...
Hi!
Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
3) restart, journal replay
Corruption comes here. The journal reply tidies things up that shouldn't be tidied up. They shouldn't be tidied up because once we reload the image, things should be in the same state as prior to suspend. If replay frees a block (thinking it wasn't properly linked or something similar), it introduces corruption.
Quoted 4 lines
No, this will not happen. All swapfile blocks must be allocated by swapon time. It is just a chunk of disk and replay will not touch it.
That's for ext3, and no other filesystems journal data anyway...
Its not about data.
Corruption is not in suspended image. Imagine you have running system (X open, applications running, gcc compiling) and someone runs journal replay. Bye bye data. And that's what happens there. When you restore, restored kernel no longer knows you did replay.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 18 lines · Pavel Machek
Quoted 18 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines · Andrew Morton
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
3) restart, journal replay
Corruption comes here. The journal reply tidies things up that shouldn't be tidied up. They shouldn't be tidied up because once we reload the image, things should be in the same state as prior to suspend. If replay frees a block (thinking it wasn't properly linked or something similar), it introduces corruption.
No, this will not happen. All swapfile blocks must be allocated by swapon time. It is just a chunk of disk and replay will not touch it.
Quoted 8 lines
Quoted 1 line
That's for ext3, and no other filesystems journal data anyway...
Its not about data.
Corruption is not in suspended image. Imagine you have running system (X open, applications running, gcc compiling) and someone runs journal replay. Bye bye data. And that's what happens there. When you restore, restored kernel no longer knows you did replay.
Wouldn't that be true in all cases where you have a journaled filesystem and you suspend? Are you talking about someone restarting system (without doing a resume), mounting the file system (causing journal replay), and then shutting down and going back to the suspended image?
I think the important thing to note is that if you don't unmount the filesystem during suspend, then no journal recovery will take place at resume time, because you are not really mounting the filesystem at all. And I can't see how you could be unmounting the filesystems without killing all of the applications, at which point it would make suspend pretty useless.
What is also important to note is that during normal filesystem operation, the ext3 journaling code never reads back any data from the journal, with the exception of a couple of fields in the journal superblock. I would hazard a guess that if you did a suspend, wiped the journal, and then resumed the journaling code wouldn't know the difference.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Hi!
Quoted 21 lines
Quoted 21 lines
Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
3) restart, journal replay
Corruption comes here. The journal reply tidies things up that shouldn't be tidied up. They shouldn't be tidied up because once we reload the image, things should be in the same state as prior to suspend. If replay frees a block (thinking it wasn't properly linked or something similar), it introduces corruption.
Quoted 4 lines
No, this will not happen. All swapfile blocks must be allocated by swapon time. It is just a chunk of disk and replay will not touch it.
That's for ext3, and no other filesystems journal data anyway...
Its not about data.
Quoted 7 lines
Quoted 4 lines
Corruption is not in suspended image. Imagine you have running system (X open, applications running, gcc compiling) and someone runs journal replay. Bye bye data. And that's what happens there. When you restore, restored kernel no longer knows you did replay.
Wouldn't that be true in all cases where you have a journaled filesystem and you suspend?
No. In normal state you restore without mounting anything (thus no journal replay).
Quoted 3 lines
Are you talking about someone restarting system (without doing a resume), mounting the file system (causing journal replay), and then shutting down and going back to the suspended image?
No, I'm not.
Quoted 6 lines
I think the important thing to note is that if you don't unmount the filesystem during suspend, then no journal recovery will take place at resume time, because you are not really mounting the filesystem at all. And I can't see how you could be unmounting the filesystems without killing all of the applications, at which point it would make suspend pretty useless.
No, I'm not unmounting it.
Quoted 5 lines
What is also important to note is that during normal filesystem operation, the ext3 journaling code never reads back any data from the journal, with the exception of a couple of fields in the journal superblock. I would hazard a guess that if you did a suspend, wiped the journal, and then resumed the journaling code wouldn't know the difference.
That's possible, but I do not want suspend to know about filesystem specifics.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 13 lines · Pavel Machek
Quoted 2 lines · Andreas Dilger
Wouldn't that be true in all cases where you have a journaled filesystem and you suspend?
No. In normal state you restore without mounting anything (thus no journal replay).
Quoted 3 lines
Are you talking about someone restarting system (without doing a resume), mounting the file system (causing journal replay), and then shutting down and going back to the suspended image?
No, I'm not.
Quoted 8 lines
Quoted 6 lines
I think the important thing to note is that if you don't unmount the filesystem during suspend, then no journal recovery will take place at resume time, because you are not really mounting the filesystem at all. And I can't see how you could be unmounting the filesystems without killing all of the applications, at which point it would make suspend pretty useless.
No, I'm not unmounting it.
OK, then why all of the talk earlier saying that journal recovery will corrupt a swapfile? That was the reason journaling was brought into the discussion in the first place:
"And now you have kernel which expects data still in journal (that was
state before suspend), but reality on disk is quite different (journal was replayed). Data corruption." -- Pavel
If the filesystem was not unmounted and remounted, then no replay will happen. End of story. If the suspend code is doing something like:
1) save memory contents to disk
2) suspend/power off
3) reboot kernel, mount filesystem(s), etc
4) check for presence of suspend image
5) replace currently-running kernel with suspended kernel
Then you are in for a world of hurt regardless of whether the data is in a swap file or a swap partition. The data in the swapfile isn't touched by journal replay at all (so that is safe regardless), but the rest of the filesystem is, which could cause strange disk corruption since the in-memory data doesn't match the on-disk data.
If that is the case, then the only way to avoid this would be to call sync_super_lockfs() on each filesystem before the suspend, which will force the journal to be empty when it returns. That API is supported by all of the journaling filesystems, and is probably a good thing to do anyways, as it will potentially free a lot of dirty data from RAM, and also ensure that the on-disk data is consistent in case the resume isn't handled gracefully.
Quoted 8 lines
Quoted 5 lines
What is also important to note is that during normal filesystem operation, the ext3 journaling code never reads back any data from the journal, with the exception of a couple of fields in the journal superblock. I would hazard a guess that if you did a suspend, wiped the journal, and then resumed the journaling code wouldn't know the difference.
That's possible, but I do not want suspend to know about filesystem specifics.
This was just given as a counterexample saying that the in-kernel ext3 journal code does not actually care what is in the journal on disk, since it is never read unless there is a crash. So, the suspend code does not need to know anything about the filesystem specifics at all in this regard.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 8 lines · Andreas Dilger
On Apr 24, 2003 22:48 +0200, Pavel Machek wrote:
OK, then why all of the talk earlier saying that journal recovery will corrupt a swapfile? That was the reason journaling was brought into the discussion in the first place:"And now you have kernel which expects data still in journal (that was
state before suspend), but reality on disk is quite different (journal was replayed). Data corruption." -- Pavel
I don't believe Pavel was saying the image would be corrupted. Rather, the rest of the disk contents are corrupted by replaying the journal and then resuming back to a memory state that has been made inconsistent with the disk state because of the journal replay.
Quoted 6 lines
If the filesystem was not unmounted and remounted, then no replay will happen. End of story. If the suspend code is doing something like:
1) save memory contents to disk
2) suspend/power off
3) reboot kernel, mount filesystem(s), etc
This is just reboot kernel. Filesystems aren't mounted before (4).
Quoted 8 lines
4) check for presence of suspend image
5) replace currently-running kernel with suspended kernelThen you are in for a world of hurt regardless of whether the data is in a swap file or a swap partition. The data in the swapfile isn't touched by journal replay at all (so that is safe regardless), but the rest of the filesystem is, which could cause strange disk corruption since the in-memory data doesn't match the on-disk data.
On the second part, "Precisely."
Quoted 7 lines
If that is the case, then the only way to avoid this would be to call
sync_super_lockfs()on each filesystem before the suspend, which will force the journal to be empty when it returns. That API is supported by all of the journaling filesystems, and is probably a good thing to do anyways, as it will potentially free a lot of dirty data from RAM, and also ensure that the on-disk data is consistent in case the resume isn't handled gracefully.
Sounds like a good idea to me.
Regards,
Nigel
Hi!
Quoted 5 lines
Quoted 5 lines · Pavel Machek
OK, then why all of the talk earlier saying that journal recovery will corrupt a swapfile? That was the reason journaling was brought into the discussion in the first place:
Quoted 8 lines
Quoted 3 lines
"And now you have kernel which expects data still in journal (that was
state before suspend), but reality on disk is quite different (journal was replayed). Data corruption." -- PavelI don't believe Pavel was saying the image would be corrupted. Rather, the rest of the disk contents are corrupted by replaying the journal and then resuming back to a memory state that has been made inconsistent with the disk state because of the journal replay.
Right.
Quoted 9 lines
Quoted 7 lines
If that is the case, then the only way to avoid this would be to call
sync_super_lockfs()on each filesystem before the suspend, which will force the journal to be empty when it returns. That API is supported by all of the journaling filesystems, and is probably a good thing to do anyways, as it will potentially free a lot of dirty data from RAM, and also ensure that the on-disk data is consistent in case the resume isn't handled gracefully.Sounds like a good idea to me.
When I do sys_sync(), will it trigger that?
Pavel
Signature · 2 lines
Horseback riding is like software... ...vgf orggre jura vgf serr.
Quoted 6 lines · Pavel Machek
Quoted 4 lines
I don't believe Pavel was saying the image would be corrupted. Rather, the rest of the disk contents are corrupted by replaying the journal and then resuming back to a memory state that has been made inconsistent with the disk state because of the journal replay.
Right.
But that is happening regardless of whether a swapfile is in use or not. It is a problem whether the filesystem is journaling or not. Basically, if you are entering into a normal boot sequence and mounting filesystems and then resuming from your saved state you risk filesystem corruption.
The only way to avoid that would be for the kernel to detect the swsusp magic data in the swap partition _before_ any filesystems are mounted (probably via initramfs), and then resume from that image (which will implicitly "mount" the filesystem because it was never unmounted in that image). Then, swsusp becomes a special case of the 2-kernel-monte (or add your other favourite kernel-booting-kernel method here), where most of your kernel state is swapped out and only a limited recovery state is loaded into RAM before doing the kernel dance).
Quoted 11 lines
Quoted 9 lines
Quoted 7 lines
If that is the case, then the only way to avoid this would be to call
sync_supers_lockfs()on each filesystem before the suspend, which will force the journal to be empty when it returns. That API is supported by all of the journaling filesystems, and is probably a good thing to do anyways, as it will potentially free a lot of dirty data from RAM, and also ensure that the on-disk data is consistent in case the resume isn't handled gracefully.Sounds like a good idea to me.
When I do
sys_sync(), will it trigger that?
No, having sys_sync() do journal purging would really hurt journal fs performance. That's why I said you need to call sync_supers_lockfs(), which is unfortunately not in 2.4 kernels (available in the LVM CVS as a patch), but it does appear to be in 2.5 kernels. For journaling filesystems this is the equivalent of temporarily unmounting the filesystem and then remounting it when unlockfs() is called.
Note that you must explicitly pass a block device to lock, so that you do this before shutting down the disk device. I've never tested, but locking the filesystem probably does not prevent writing to an existing swapfile on that filesystem, since the swap code bypasses the filesystem entirely.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 13 lines · Andreas Dilger
Quoted 6 lines · Pavel Machek
Quoted 4 lines
I don't believe Pavel was saying the image would be corrupted. Rather, the rest of the disk contents are corrupted by replaying the journal and then resuming back to a memory state that has been made inconsistent with the disk state because of the journal replay.
Right.
But that is happening regardless of whether a swapfile is in use or not. It is a problem whether the filesystem is journaling or not. Basically, if you are entering into a normal boot sequence and mounting filesystems and then resuming from your saved state you risk filesystem corruption.
Quoted 8 lines
The only way to avoid that would be for the kernel to detect the swsusp magic data in the swap partition _before_ any filesystems are mounted (probably via initramfs), and then resume from that image (which will implicitly "mount" the filesystem because it was never unmounted in that image). Then, swsusp becomes a special case of the 2-kernel-monte (or add your other favourite kernel-booting-kernel method here), where most of your kernel state is swapped out and only a limited recovery state is loaded into RAM before doing the kernel dance).
And that's precisely what we do. SWSUSP runs before any file system is mounted. It checks the designed partition's swap header, loads the image and then completely replaces the booting kernel with the saved one. That's how we avoid corruption at the moment. But if we have a swapfile, we need to do some initialisation of the filesystem code in order to get access to our swapfile. Even if we record in the swapfile - while suspending - information that gives us the locations of blocks, we still need to find the start of the swapfile, or store it somewhere. If you have a suggestion in that regard, I might be able to see a swapfile as a possibility.
Regards,
Nigel
Signature · 6 lines
Nigel Cunningham 495 St Georges Road South, Hastings 4201, New Zealand Be diligent to present yourself approved to God as a workman who does not need to be ashamed, handling accurately the word of truth. -- 2 Timothy 2:14, NASB.
Quoted 3 lines · Nigel Cunningham
Even if we record in the swapfile - while
suspending - information that gives us the locations of blocks, we still need to find the start of the swapfile, or store it somewhere.
If LILO can do it...
The starting block number does not change unless you delete and recreate the swapfile. It has the same requirement for location stability as the kernel image and initrd for LILO.
So, a patched LILO could record the start of the swapfile when it is run. Note that you do this as usual when installing a kernel or when installing a new swapfile. There's no need to do it when suspending.
If you're booting with Grub or some other fs-aware bootloader, then the bootloader can presumably find the start of the swapfile just like it finds the kernel and initrd.
-- Jamie
Quoted 23 lines · Nigel Cunningham
Quoted 13 lines · Andreas Dilger
Quoted 6 lines · Pavel Machek
Quoted 4 lines
I don't believe Pavel was saying the image would be corrupted. Rather, the rest of the disk contents are corrupted by replaying the journal and then resuming back to a memory state that has been made inconsistent with the disk state because of the journal replay.
Right.
But that is happening regardless of whether a swapfile is in use or not. It is a problem whether the filesystem is journaling or not. Basically, if you are entering into a normal boot sequence and mounting filesystems and then resuming from your saved state you risk filesystem corruption.
Quoted 8 lines
The only way to avoid that would be for the kernel to detect the swsusp magic data in the swap partition _before_ any filesystems are mounted (probably via initramfs), and then resume from that image (which will implicitly "mount" the filesystem because it was never unmounted in that image). Then, swsusp becomes a special case of the 2-kernel-monte (or add your other favourite kernel-booting-kernel method here), where most of your kernel state is swapped out and only a limited recovery state is loaded into RAM before doing the kernel dance).
Quoted 4 lines
And that's precisely what we do. SWSUSP runs before any file system is mounted. It checks the designed partition's swap header, loads the image and then completely replaces the booting kernel with the saved one. That's how we avoid corruption at the moment.
OK, then journal replay is again out of the picture... It's just hard to follow because one person says "journal replay will corrupt things", and the other says "we aren't mounting filesystems". No mounting == no journal replay == no corruption. This has nothing to do with swapfiles.
Quoted 6 lines
But if we have a swapfile, we need to do some initialisation of the filesystem code in order to get access to our swapfile. Even if we record in the swapfile - while suspending - information that gives us the locations of blocks, we still need to find the start of the swapfile, or store it somewhere. If you have a suggestion in that regard, I might be able to see a swapfile as a possibility.
Two options:
1) You already have to store _some_ information about where to get the resume image from. It sounds like you store the swap partition name on the kernel command-line or similar. It should be equally possible to store the swap file partition name PLUS a relative offset from the start of the partition to where the swapfile starts. You can easily get this via fstat+bmap on the swapfile.
2) You could require that the critical resume information be on a swap partition, but allow non-kernel data to be saved to the swapfile. If you can read the initial resume data from the swap partition, I'd have to imagine that you can read devno+block data from a swapfile without needing any of the filesystem code involved. After all, the swap code doesn't depend on the filesystem either - it just makes a list of block numbers at swapfile activation time and does direct read/write to the device after that.
The lilo suggestion for doing the bmap could also be done, although I don't see the need if the swap code has already mapped the entire file in memory already. Also note - while GRUB _examines_ the filesystem (via internal fs-aware code), I don't think it acutally mounts it or does journal replay, so it should be safe also if you really wanted to go that way (I don't think you need to however).
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Hi!
Quoted 9 lines
Quoted 3 lines
Quoted 1 line
Sounds like a good idea to me.
When I do
sys_sync(), will it trigger that?No, having
sys_sync()do journal purging would really hurt journal fs performance. That's why I said you need to callsync_supers_lockfs(), which is unfortunately not in 2.4 kernels (available in the LVM CVS as a patch), but it does appear to be in 2.5 kernels. For journaling
(Second thought).
Its okay. We do sys_sync. If machine fails to resume, normal journal recovery happens; nothing bad. It would be nice to sync_supers_lockfs(), but if we need to have list of block devices for that, its just too much trouble. Data are safe, anyway.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 7 lines · Nigel Cunningham
Quoted 6 lines · Andrew Morton
Quoted 6 lines
Quoted 6 lines
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
3) restart, journal replay
Corruption comes here. The journal reply tidies things up that shouldn't be tidied up. They shouldn't be tidied up because once we reload the image, things should be in the same state as prior to suspend. If replay frees a block (thinking it wasn't properly linked or something similar), it introduces corruption.
This has nothing to do with using a swapfile.
But if you resume from swsusp, you don't really `mount' all file systems. They are implicitly mounted because they were mounted before the suspend operation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Followup to: <[email protected]> By author: Geert Uytterhoeven <[email protected]> In newsgroup: linux.dev.kernel
Quoted 17 lines · Nigel Cunningham
Quoted 7 lines · Andrew Morton
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Sorry, I still don't get it. Go through the steps for me:
1) suspend writes pages to disk
2) machine is shutdown
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
3) restart, journal replay
Corruption comes here. The journal reply tidies things up that shouldn't be tidied up. They shouldn't be tidied up because once we reload the image, things should be in the same state as prior to suspend. If replay frees a block (thinking it wasn't properly linked or something similar), it introduces corruption.
Quoted 5 lines
This has nothing to do with using a swapfile.
But if you resume from swsusp, you don't really `mount' all file systems. They are implicitly mounted because they were mounted before the suspend operation.
Shouldn't we be syncing them all before the suspend anyway, to minimize corruption in case the user chooses to mount the filesystem *without* resuming (think a dual-boot configuration.) This would be another application for the "supersync" operation that was discussed at OLS 2002 -- a need for an operation which not only flushes all blocks to disk but also forces the journal to be replayed and truncated.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
It would be nice, so GRUB has no problem any more for using journaling file system on boot partition.
Quoted 19 lines
Shouldn't we be syncing them all before the suspend anyway, to minimize corruption in case the user chooses to mount the filesystem *without* resuming (think a dual-boot configuration.) This would be another application for the "supersync" operation that was discussed at OLS 2002 -- a need for an operation which not only flushes all blocks to disk but also forces the journal to be replayed and truncated.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: "Hua Zhong" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 4 lines
It would be nice, so GRUB has no problem any more for using journaling file system on boot partition.
Not just GRUB, but just about any boot loader which doesn't use bmap(). bmap() is apparently special-cased in ext3, but still...
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
They are synced, the journal is just not truncated.
Regards,
Nigel
Quoted 9 lines · H. Peter Anvin
Shouldn't we be syncing them all before the suspend anyway, to minimize corruption in case the user chooses to mount the filesystem *without* resuming (think a dual-boot configuration.) This would be another application for the "supersync" operation that was discussed at OLS 2002 -- a need for an operation which not only flushes all blocks to disk but also forces the journal to be replayed and truncated.
-hpa
Signature · 6 lines
Nigel Cunningham 495 St Georges Road South, Hastings 4201, New Zealand Be diligent to present yourself approved to God as a workman who does not need to be ashamed, handling accurately the word of truth. -- 2 Timothy 2:14, NASB.
Quoted 7 lines · H. Peter Anvin
By author: Geert Uytterhoeven <[email protected]>
Quoted 5 lines
This has nothing to do with using a swapfile.
But if you resume from swsusp, you don't really `mount' all file systems. They are implicitly mounted because they were mounted before the suspend operation.
Quoted 7 lines
Shouldn't we be syncing them all before the suspend anyway, to minimize corruption in case the user chooses to mount the filesystem *without* resuming (think a dual-boot configuration.) This would be another application for the "supersync" operation that was discussed at OLS 2002 -- a need for an operation which not only flushes all blocks to disk but also forces the journal to be replayed and truncated.
This "supersync" already exists, and it is supported by all of the journaling filesystems for LVM snapshots. This is the VFS method write_super_lockfs in the ext3/reiserfs/XFS/JFS super_operations. Not only does it sync the dirty data to disk, but it also forces the journal to be empty and marks the filesystem clean, so that it can be snapshotted and read-only mounted (basically equivalent to unmounting the filesystem).
Unfortunately, even though the filesystems themselves have supported this VFS method for a long time, the actual code that calls these methods (sync_super_lockfs() and unlockfs()) are still only available as a patch from LVM. The LVM/reiserfs folks have talked about submitting it to Marcelo for a long time now, but apparently still haven't done so.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 9 lines · Andreas Dilger
This "supersync" already exists, and it is supported by all of the journaling filesystems for LVM snapshots. This is the VFS method
write_super_lockfsin the ext3/reiserfs/XFS/JFSsuper_operations. Not only does it sync the dirty data to disk, but it also forces the journal to be empty and marks the filesystem clean, so that it can be snapshotted and read-only mounted (basically equivalent to unmounting the filesystem).
Quoted 6 lines
Unfortunately, even though the filesystems themselves have supported this VFS method for a long time, the actual code that calls these methods (
sync_super_lockfs()andunlockfs()) are still only available as a patch from LVM. The LVM/reiserfs folks have talked about submitting it to Marcelo for a long time now, but apparently still haven't done so.
I really think this should be made available. Perhaps we should have a sync1() system call which takes a flag set. Then we could have sync1(SYNC_FLUSH_JOURNALS);
-hpa
Hi!
Quoted 9 lines
Quoted 4 lines
If you really want to "solve" it reliably, you can always
swapon
/dev/hdfoo666Seems that using a swapfile instead of a swapdev would fix that neatly.
But iirc, suspend doesn't work with swapfiles. Is that correct? If so, what has to be done to get it working?
Swapfile does not work, because even readonly mount wants to replay logs, and that'd be disk corruption.
It could be doable with modifications to the filesystems, but it would be hard (and I do not think it is worth it).
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 8 lines · Pavel Machek
Hi!
Quoted 5 lines
Quoted 4 lines
If you really want to "solve" it reliably, you can always
swapon
/dev/hdfoo666
Quoted 8 lines
Quoted 4 lines
Seems that using a swapfile instead of a swapdev would fix that neatly.
But iirc, suspend doesn't work with swapfiles. Is that correct? If so, what has to be done to get it working?
Swapfile does not work, because even readonly mount wants to replay logs, and that'd be disk corruption.
I don't get it. Can you explain some more?
Hi!
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
If you really want to "solve" it reliably, you can always
swapon
/dev/hdfoo666Seems that using a swapfile instead of a swapdev would fix that neatly.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
But iirc, suspend doesn't work with swapfiles. Is that correct? If so, what has to be done to get it working?
Swapfile does not work, because even readonly mount wants to replay logs, and that'd be disk corruption.
I don't get it. Can you explain some more?
See other mail about 3 minutes ago from me... I hope its clear there.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 2 lines · Pavel Machek
Swapfile does not work, because even readonly mount wants to replay logs, and that'd be disk corruption.
I don't understand. During suspend, you just need a list of blocks to write to from the swapfile. You can get that list before starting the actual suspend, so that writing doesn't imply any filesystem activity.
When you're resuming, you just need a list of which disk blocks to resume from. Can't that list be stored in a few blocks of the swapfile itself, with the only critical parameter being the first block number to resume from?
(A bit like LILO has a map file containing the list of blocks which contain the kernel to boot.)
-- Jamie
Hi!
Quoted 11 lines
Quoted 2 lines
Swapfile does not work, because even readonly mount wants to replay logs, and that'd be disk corruption.
I don't understand. During suspend, you just need a list of blocks to write to from the swapfile. You can get that list before starting the actual suspend, so that writing doesn't imply any filesystem activity.
When you're resuming, you just need a list of which disk blocks to resume from. Can't that list be stored in a few blocks of the swapfile itself, with the only critical parameter being the first block number to resume from?
And how do you pass that first number? Please user could you write this down to paper and enter it on commandline during suspend?
Okay, okay, this could be made to work. You could store pointer in swapspace or in reserved block somewhere...
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 14 lines · Pavel Machek
Hi!
Quoted 9 lines
Quoted 4 lines
If you really want to "solve" it reliably, you can always
swapon
/dev/hdfoo666Seems that using a swapfile instead of a swapdev would fix that neatly.
But iirc, suspend doesn't work with swapfiles. Is that correct? If so, what has to be done to get it working?
Quoted 7 lines
Swapfile does not work, because even readonly mount wants to replay logs, and that'd be disk corruption.
It could be doable with modifications to the filesystems, but it would be hard (and I do not think it is worth it).
Pavel
Any non-journaling filesystem should work out fine. And if you don't trust ext2, you can still use xiafs once I've finished porting it to 2.5
Carl-Daniel
Signature · 1 line
http://www.hailfinger.org/
Good Morning,
Quoted 10 lines · On Thu, 24 Apr 2003 10:25:25 +1200 Nigel Cunningham <[email protected]>…
Quoted 4 lines · Marc Giger
Ok! I see the advantages / disadvantages of each version. But what happens if the memory AND swap space are full and nothing can't be freed? When I watch the memory and swap consumption on my laptop, I think it's the most time the case...
If you're getting yourself in that situation, you should be increasing your swap space (and memory if possible) anyway.
Yeah, you are right but it was always enough. It was rarely the case that something got killed...I can't install more ram, 256MB is the maximum:-( and i don't want to repartition my harddisk..(~250MB swap)
Quoted 9 lines
Quoted 8 lines
Another question:
Is it a big problem to save the memory in a separate file on the file system, and save somewhere the pointer to it (as example in swap. Also we could set a flag in swap so that we now that the last shutdown was a hybernation). One Problem will be, that we don't know the filesystem type on resume...(We could save the module in swap...)
All that is just theoretical. It's only a idea.
Quoted 6 lines
I guess the simplest answer is would it be worth the pain? Since disk space is cheap, it just requires a little forethought when installing Linux, to ensure enough swap is allocated. I certainly understand that using a file rather than swap makes adjusting the amount of space available easier, but as you rightly acknowledge, it does complicate things a fair bit more.
Yes I see, but there are a lot of users (like me) who has an already installed Linux and don't want to repartition the disk and reinstall it. Repartitioning Programs success is not always guaranteed...
Marc