Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
>> > While that would certainly be nifty, I think we're arguably starting
>> > from the wrong point here. Why are we booting a kernel, trying to poke
>> > the hardware back into some sort of mock-quiescent state, freeing memory
>> > and then (fin
We used it (with great success) to replace bad UPSs on single-PSU
database servers under (light) load. No need for scheduled downtime,
etc.
The whole point of hibernation (or suspend to disk, or whatever you
call it) is that the system goes to a zero-power state and then can be
brought back to it
Hi!
> I don't dispute that it sometimes works today.
>
> what I dispute is that makeing it work should be a contraint on a cleaner
> design that happens to cause tcp connections to fail on suspend-to-disk
> (hibernate).
>
> if you are dong suspend-to-disk for such a short period that TCP
> co
On Mon, 7 May 2007, Pavel Machek wrote:
Really? It works today... if the suspend is short
enough. And that's
how it should be.
If we get very good at Wake-on-Lan it should work for
any length
of time.
for suspend-to-ram this would work, I stand corrected.
for hibernate this would almost cer
Hi!
> >>Really? It works today... if the suspend is short
> >>enough. And that's
> >>how it should be.
> >
> >If we get very good at Wake-on-Lan it should work for
> >any length
> >of time.
>
> for suspend-to-ram this would work, I stand corrected.
>
> for hibernate this would almost certinly
On Mon, 7 May 2007, Oliver Neukum wrote:
Am Montag, 7. Mai 2007 14:48 schrieb Pavel Machek:
Including network? Your tcp peers will be really confused, then, if
you ACK packets then claim you did not get them. No, you do not want
to start network.
anyone who is doing a hibernate or suspend who
Hi!
> nobody is suggesting that you leave peocesses running
> while you do the snapshot, what is being proposed is
>
> 1. pause userspace (prevent scheduling)
> 2. make snapshot image of memory
> 3. make mounted filesystems read-only (possibly with
> snapshot/checkpoint)
> 4. unpause
> 5. save
Hi!
> > The "let's stop all kernel threads" is superstition. It's the same kind of
> > superstition that made people write "sync" three times before turning off
> > the power in the olden times. It's the kind of superstition that comes
> > from "we don't do things right, so let's be vewy vewy q
Am Montag, 7. Mai 2007 14:48 schrieb Pavel Machek:
> > >Including network? Your tcp peers will be really confused, then, if
> > >you ACK packets then claim you did not get them. No, you do not want
> > >to start network.
> >
> > anyone who is doing a hibernate or suspend who expect all the network
Hi!
> >>nobody is suggesting that you leave peocesses running
> >>while you do the snapshot, what is being proposed is
> >>
> >>1. pause userspace (prevent scheduling)
> >>2. make snapshot image of memory
> >>3. make mounted filesystems read-only (possibly with
> >>snapshot/checkpoint)
> >>4. unpa
On May 06, 2007, at 22:13:51, David Lang wrote:
anyone who is doing a hibernate or suspend who expect all the
network connections to be working afterwords is dreaming or
smokeing something.
this is just another way that the failure can show up.
in fact, I would say that it would probalby be
On Thu, 3 May 2007, Pavel Machek wrote:
Hi!
nobody is suggesting that you leave peocesses running
while you do the snapshot, what is being proposed is
1. pause userspace (prevent scheduling)
2. make snapshot image of memory
3. make mounted filesystems read-only (possibly with
snapshot/checkpo
Hello,
On Sat, May 5, 2007 11:16, Pavel Machek wrote:
>> But the same functionality can be achieved by doing:
>>
>> 1) Define a user password (e.g. /etc/shadow thing). (Once)
>>
>> 2) When a user logs in: get random data and encrypt it with the password,
>> this becomes the AES key. Store both the
Hi!
> But the same functionality can be achieved by doing:
>
> 1) Define a user password (e.g. /etc/shadow thing). (Once)
>
> 2) When a user logs in: get random data and encrypt it with the password,
> this becomes the AES key. Store both the data and key in a secure way in
> memory, e.g. using
On Thu, May 3, 2007 14:06, Pavel Machek wrote:
>> > > The kernel can already do compression and encryption.
>> >
>> > Yes, if we all could agree on _which_ compression and encryption
>>
>> Any of those available in the kernel. Where's the problem?
>
> gzip is too slow for this. lzf works okay. Oh a
On May 04, 2007, at 03:52:03, David Greaves wrote:
Kyle Moffett wrote:
On May 03, 2007, at 11:10:47, Pavel Machek wrote:
What happens if you try to boot and filesystems are frozen from
previous run?
If you're just doing a fresh boot then the filesystem is already
clean due to the dm freeze
Kyle Moffett wrote:
> On May 03, 2007, at 11:10:47, Pavel Machek wrote:
>> How mature is freezing filesystems -- will it work on at least ext2/3
>> and vfat?
>
> I'm pretty sure it works on ext2/3 and xfs and possibly others, I don't
> know either way about VFAT though. Essentially the "freeze" p
On May 03, 2007, at 11:10:47, Pavel Machek wrote:
How mature is freezing filesystems -- will it work on at least
ext2/3 and vfat?
I'm pretty sure it works on ext2/3 and xfs and possibly others, I
don't know either way about VFAT though. Essentially the "freeze"
part involves telling the f
Hi!
> > 1) if the kernel threads are frozen, we know that they don't hold any locks
> > that could interfere with the freezing of device drivers,
> > 2) if they are frozen, we know, for example, that they won't call user mode
> > helpers or do similar things,
> > 3) if they are frozen, we know tha
Hi!
> >>It makes it harder to debug (wouldn't it be *nice* to
> >>just ssh in, and do
> >>gdb -p
> >
> >Make the machine being suspended a VM and you can
> >already do that.
>
> >>when something goes wrong?) but we also *depend* on
> >>user space for various things (the same way we depe
Hi!
> > > The kernel can already do compression and encryption.
> >
> > Yes, if we all could agree on _which_ compression and encryption
>
> Any of those available in the kernel. Where's the problem?
gzip is too slow for this. lzf works okay. Oh and swsusp wants rsa
crypto.
Hi!
> > While that would certainly be nifty, I think we're arguably starting
> > from the wrong point here. Why are we booting a kernel, trying to poke
> > the hardware back into some sort of mock-quiescent state, freeing memory
> > and then (finally) overwriting the entire contents of RAM rath
On Sunday, 29 April 2007 10:59, Pavel Machek wrote:
> Hi!
>
> > > Ie we do have history of _not_ freezing things. The freezing came later,
> > > and came with the subsystem that had more problems..
> >
> > It doesn't have that many problems as you are trying to suggest. At
> > present,
> > th
On Sunday, 29 April 2007 10:23, Pavel Machek wrote:
> Hi!
>
> > > > The freezer has *caused* those deadlocks (eg by stopping threads that
> > > > were
> > > > needed for the suspend writeouts to succeed!), not solved them.
> > >
> > > I can't remember anything like this, but I believe you have
Hi!
> > Ie we do have history of _not_ freezing things. The freezing came later,
> > and came with the subsystem that had more problems..
>
> It doesn't have that many problems as you are trying to suggest. At present,
> the only problems with it happen if someone tries to "improve" it in the
On Sunday, 29 April 2007 01:45, Linus Torvalds wrote:
>
> On Sun, 29 Apr 2007, Rafael J. Wysocki wrote:
> >
> > OK, more precisely: fs-related threads should not try to process their
> > queues,
> > etc., after the snapshot is done, because that may cause some fs data to be
> > written at that t
Hi!
> > > The freezer has *caused* those deadlocks (eg by stopping threads that
> > > were
> > > needed for the suspend writeouts to succeed!), not solved them.
> >
> > I can't remember anything like this, but I believe you have a specific test
> > case in mind.
>
> Ehh.. Why do you thik we _h
On Apr 28, 2007, at 19:45:01, Linus Torvalds wrote:
On Sun, 29 Apr 2007, Rafael J. Wysocki wrote:
Well, I'm not sure whether or not that still would have been the
case if we had stopped to freeze kernel threads for the
hibernation/suspend.
Did you miss the email where Paul pointed out that
Hi.
On Sat, 2007-04-28 at 16:45 -0700, Linus Torvalds wrote:
>
> On Sun, 29 Apr 2007, Rafael J. Wysocki wrote:
> >
> > OK, more precisely: fs-related threads should not try to process their
> > queues,
> > etc., after the snapshot is done, because that may cause some fs data to be
> > written a
On Sun, 29 Apr 2007, Rafael J. Wysocki wrote:
>
> OK, more precisely: fs-related threads should not try to process their queues,
> etc., after the snapshot is done, because that may cause some fs data to be
> written at that time and then the fs in question may be corrupted after the
> restore.
On Saturday, 28 April 2007 23:25, Linus Torvalds wrote:
>
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> > >
> > > The freezer has *caused* those deadlocks (eg by stopping threads that
> > > were
> > > needed for the suspend writeouts to succeed!), not solved them.
> >
> > I can't remember
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> >
> > The freezer has *caused* those deadlocks (eg by stopping threads that were
> > needed for the suspend writeouts to succeed!), not solved them.
>
> I can't remember anything like this, but I believe you have a specific test
> case in mind.
On Saturday, 28 April 2007 20:43, David Lang wrote:
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> > On Friday, 27 April 2007 12:12, Pekka J Enberg wrote:
> >> The problem with writing in the kernel is obvious: we need to add new code
> >> to the kernel for compression, encryption, and userspace
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
On Saturday, 28 April 2007 20:32, David Lang wrote:
On Sat, 28 Apr 2007, Pavel Machek wrote:
We freeze user space processes for the reasons that you have quoted above.
Why we freeze kernel threads in there too is a good question, but not for me
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
On Friday, 27 April 2007 12:12, Pekka J Enberg wrote:
The problem with writing in the kernel is obvious: we need to add new code
to the kernel for compression, encryption, and userspace interaction
(graphical progress bar) that are important for user
On Saturday, 28 April 2007 20:32, David Lang wrote:
> On Sat, 28 Apr 2007, Pavel Machek wrote:
>
> >>
> >> We freeze user space processes for the reasons that you have quoted above.
> >>
> >> Why we freeze kernel threads in there too is a good question, but not for
> >> me to
> >> answer. I don'
On Sat, 28 Apr 2007, Pavel Machek wrote:
We freeze user space processes for the reasons that you have quoted above.
Why we freeze kernel threads in there too is a good question, but not for me to
answer. I don't know. Pavel should know, I think.
We do not want kernel threads running:
a) t
Nigel Cunningham wrote:
Please, go apply that logic elsewhere, then cut out (or at least stop
adding) support for users with less common needs in other areas. I fully
acknowledge that most users have only one place to store their image and
it's a swap device. But that doesn't mean one size fits
On Sat, 28 Apr 2007, Oliver Neukum wrote:
Am Samstag, 28. April 2007 01:50 schrieb David Lang:
3. make mounted filesystems read-only (possibly with snapshot/checkpoint)
4. unpause
5. save image (with full userspace available, including network)
6. shutdown system (throw away all userspace memor
On Saturday, 28 April 2007 18:28, Linus Torvalds wrote:
>
> On Sat, 28 Apr 2007, Pavel Machek wrote:
> >
> > We do not want kernel threads running:
> >
> > a) they may hold some locks and deadlock suspend
> >
> > b) they may do some writes to disk, leading to corruption
>
> You're really just
On Sat, 28 Apr 2007, Pavel Machek wrote:
>
> We do not want kernel threads running:
>
> a) they may hold some locks and deadlock suspend
>
> b) they may do some writes to disk, leading to corruption
You're really just making both of those up.
If a kernel thread holds a lock and deadlocks sus
Am Samstag, 28. April 2007 11:22 schrieb Pekka Enberg:
> Hi Oliver,
>
> Am Freitag, 27. April 2007 12:12 schrieb Pekka J Enberg:
> > > The problem with writing in the kernel is obvious: we need to add new code
> > > to the kernel for compression, encryption, and userspace interaction
> > > (graphi
Pavel Machek <[EMAIL PROTECTED]> wrote:
>> I also don't like the idea of storing this in the swap partition for a
>> couple of reasons.
>>
>> 1. on many modern linux systems the swap partition is not large enough.
>>
>> for example, on my boxes with 16G or ram I only allocate 2G of swap
>> space
On Friday, 27 April 2007 12:12, Pekka J Enberg wrote:
> Am Freitag, 27. April 2007 08:18 schrieb Pekka J Enberg:
> > > No. The snapshot is just that. A snapshot in time. From kernel point of
> > > view, it doesn't matter one bit what when you did it or if the state has
> > > changed before you re
Hi Oliver,
Am Freitag, 27. April 2007 12:12 schrieb Pekka J Enberg:
> The problem with writing in the kernel is obvious: we need to add new code
> to the kernel for compression, encryption, and userspace interaction
> (graphical progress bar) that are important for user experience.
On 4/27/07,
On Saturday, 28 April 2007 10:50, Pavel Machek wrote:
> Hi!
>
> > > In many ways, "at all".
> > >
> > > I _do_ realize the IO request queue issues, and that we cannot actually
> > > do
> > > s2ram with some devices in the middle of a DMA. So we want to be able to
> > > avoid *that*, there's no
On Sat, 28 Apr 2007, Oliver Neukum wrote:
> And then you'll have people wonder why the server which sent out all
> those files has no log entries. You'd have to selectively unfreeze user
> space, which is a cure worse than the desease.
>
> Simply throwing away user space work is a bug. And no, you
Am Samstag, 28. April 2007 01:50 schrieb David Lang:
> 3. make mounted filesystems read-only (possibly with snapshot/checkpoint)
> 4. unpause
> 5. save image (with full userspace available, including network)
> 6. shutdown system (throw away all userspace memory, no need to do graceful
> shutdo
Hi!
> > In many ways, "at all".
> >
> > I _do_ realize the IO request queue issues, and that we cannot actually do
> > s2ram with some devices in the middle of a DMA. So we want to be able to
> > avoid *that*, there's no question about that. And I suspect that stopping
> > user threads and the
Hi!
> > > > > It's doubly bad, because that idiocy has also infected s2ram. Again,
> > > > > another thing that really makes no sense at all - and we do it not
> > > > > just for snapshotting, but for s2ram too. Can you tell me *why*?
> > > >
> > > > Why we freeze tasks at all or why we freeze ker
On Friday 27 April 2007 21:44:48 Rafael J. Wysocki wrote:
> On Saturday, 28 April 2007 03:12, Linus Torvalds wrote:
> > On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> > > > It's doubly bad, because that idiocy has also infected s2ram. Again,
> > > > another thing that really makes no sense at all
On Saturday, 28 April 2007 03:12, Linus Torvalds wrote:
>
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> >
> > > It's doubly bad, because that idiocy has also infected s2ram. Again,
> > > another thing that really makes no sense at all - and we do it not just
> > > for snapshotting, but for
On Fri, 27 Apr 2007, Linus Torvalds wrote:
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
It's doubly bad, because that idiocy has also infected s2ram. Again,
another thing that really makes no sense at all - and we do it not just
for snapshotting, but for s2ram too. Can you tell me *why*?
W
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
On Saturday, 28 April 2007 03:03, Kyle Moffett wrote:
On Apr 27, 2007, at 18:07:46, Nigel Cunningham wrote:
Hi.
On Fri, 2007-04-27 at 14:44 -0700, Linus Torvalds wrote:
It makes it harder to debug (wouldn't it be *nice* to just ssh in,
and do
On Apr 27, 2007, at 21:15:28, Rafael J. Wysocki wrote:
On Saturday, 28 April 2007 03:03, Kyle Moffett wrote:
On Apr 27, 2007, at 18:07:46, Nigel Cunningham wrote:
But in doing so you make the contents of the disk inconsistent
with the state you've just snapshotted, leading to filesystem
corr
Nigel Cunningham nigel.suspend2.net> writes:
> 4) uswsusp and swsusp get dropped and Suspend2 goes into mainline.
After reading most of this thread, it seems that Linus is of the view that all
three of these suck in one way or another. Suspend2 has the most features and is
the fastest of the lot
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>
> > It's doubly bad, because that idiocy has also infected s2ram. Again,
> > another thing that really makes no sense at all - and we do it not just
> > for snapshotting, but for s2ram too. Can you tell me *why*?
>
> Why we freeze tasks at all o
On Saturday, 28 April 2007 03:03, Kyle Moffett wrote:
> On Apr 27, 2007, at 18:07:46, Nigel Cunningham wrote:
> > Hi.
> >
> > On Fri, 2007-04-27 at 14:44 -0700, Linus Torvalds wrote:
> >> It makes it harder to debug (wouldn't it be *nice* to just ssh in,
> >> and do
> >>gdb -p
> >
> > Make t
On Saturday, 28 April 2007 03:00, Matthew Garrett wrote:
> On Fri, Apr 27, 2007 at 05:18:16PM -0700, Jeremy Fitzhardinge wrote:
>
> > Then you could use kexec for resume...
>
> While that would certainly be nifty, I think we're arguably starting
> from the wrong point here. Why are we booting a
On Apr 27, 2007, at 18:07:46, Nigel Cunningham wrote:
Hi.
On Fri, 2007-04-27 at 14:44 -0700, Linus Torvalds wrote:
It makes it harder to debug (wouldn't it be *nice* to just ssh in,
and do
gdb -p
Make the machine being suspended a VM and you can already do that.
when something go
Matthew Garrett wrote:
> While that would certainly be nifty, I think we're arguably starting
> from the wrong point here. Why are we booting a kernel, trying to poke
> the hardware back into some sort of mock-quiescent state, freeing memory
> and then (finally) overwriting the entire contents o
On Fri, Apr 27, 2007 at 05:18:16PM -0700, Jeremy Fitzhardinge wrote:
> Then you could use kexec for resume...
While that would certainly be nifty, I think we're arguably starting
from the wrong point here. Why are we booting a kernel, trying to poke
the hardware back into some sort of mock-quie
On Saturday, 28 April 2007 01:59, Linus Torvalds wrote:
>
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> >
> > Actually, the less things happen while we're creating and saving the image,
> > the less sources of potential problems there are and by freezing the kernel
> > threads (not all of them
Linus Torvalds writes:
> I really don't see how you can say that stopping threads etc can make any
> difference what-so-ever. If you don't create the snapshot with interrupts
> disabled (and just with a single CPU running) you have so many other
> problems that it's not even remotely funny.
I
On Fri, 27 Apr 2007, David Lang wrote:
>
> all that's needed for the snapshot is to prevent userspace from scheduling,
Strictly speaking, all you *really* want to make sure is not so much that
user-space isn't scheduling, as the fact that all device IO buffers must
be empty.
We can trivially
On Sat, 28 Apr 2007, Nigel Cunningham wrote:
Hi.
On Sat, 2007-04-28 at 01:45 +0200, Rafael J. Wysocki wrote:
On Saturday, 28 April 2007 01:17, Linus Torvalds wrote:
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
And can you name a _single_ advantage of doing so?
Yes. We have a lot less
On Fri, 27 Apr 2007, Linus Torvalds wrote:
>
> The "let's stop all kernel threads" is superstition. It's the same kind of
> superstition that made people write "sync" three times before turning off
> the power in the olden times. It's the kind of superstition that comes
> from "we don't do th
Linus Torvalds wrote:
> On Fri, 27 Apr 2007, Rafael J. Wysocki wrote:
>
>> Why do you think that keeping the user space frozen after 'snapshot' is a bad
>> idea? I think that solves many of the problems you're discussing.
>>
>
> It makes it harder to debug (wouldn't it be *nice* to just ss
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>
> Actually, the less things happen while we're creating and saving the image,
> the less sources of potential problems there are and by freezing the kernel
> threads (not all of them), we cause less things to happen at that time.
That makes no sens
On Saturday, 28 April 2007 01:01, David Lang wrote:
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>
> > On Saturday, 28 April 2007 00:26, David Lang wrote:
> >> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> >>
> > We're freezing many of them just fine. ;-)
>
> And can you name a
Hi.
On Sat, 2007-04-28 at 01:45 +0200, Rafael J. Wysocki wrote:
> On Saturday, 28 April 2007 01:17, Linus Torvalds wrote:
> >
> > On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> > >
> > > > And can you name a _single_ advantage of doing so?
> > >
> > > Yes. We have a lot less interdependencies
On Saturday, 28 April 2007 01:17, Linus Torvalds wrote:
>
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> >
> > > And can you name a _single_ advantage of doing so?
> >
> > Yes. We have a lot less interdependencies to worry about during the whole
> > operation.
>
> That's not an advantage. Th
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
On Saturday, 28 April 2007 00:26, David Lang wrote:
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
We're freezing many of them just fine. ;-)
And can you name a _single_ advantage of doing so?
Yes. We have a lot less interdependencies to worry
Hi.
Just to let you know - I'm not ignoring your message. It's just taking
some time to think through the issues and try to formulate a good reply.
Oh, and of course there are a gazillion other messages flying about at
the moment that need attention too.
Regards,
Nigel
signature.asc
Descriptio
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>
> > And can you name a _single_ advantage of doing so?
>
> Yes. We have a lot less interdependencies to worry about during the whole
> operation.
That's not an advantage. That's why it has *sucked*.
Trying to freeze kernel threads has _caused_ p
On Saturday, 28 April 2007 00:26, David Lang wrote:
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>
> >>> We're freezing many of them just fine. ;-)
> >>
> >> And can you name a _single_ advantage of doing so?
> >
> > Yes. We have a lot less interdependencies to worry about during the whole
> >
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
We're freezing many of them just fine. ;-)
And can you name a _single_ advantage of doing so?
Yes. We have a lot less interdependencies to worry about during the whole
operation.
It so happens, that most people wouldn't notice or care that kmi
On Fri, 27 Apr 2007, Rafael J. Wysocki wrote:
On Friday, 27 April 2007 14:49, Pavel Machek wrote:
I think this is very similar to current uswsusp design; except that we
are using read on /dev/snapshot to read the snapshot (not memory
mapping) and that we freeze the system
Yes, it seems so.
On Saturday, 28 April 2007 00:08, Linus Torvalds wrote:
>
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> >
> > We're freezing many of them just fine. ;-)
>
> And can you name a _single_ advantage of doing so?
Yes. We have a lot less interdependencies to worry about during the whole
operatio
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>
> We're freezing many of them just fine. ;-)
And can you name a _single_ advantage of doing so?
It so happens, that most people wouldn't notice or care that kmirrord got
frozen (kernel thread picked at random - it might be one of the threads
th
Hi.
On Fri, 2007-04-27 at 14:44 -0700, Linus Torvalds wrote:
>
> On Fri, 27 Apr 2007, Rafael J. Wysocki wrote:
> >
> > Why do you think that keeping the user space frozen after 'snapshot' is a
> > bad
> > idea? I think that solves many of the problems you're discussing.
>
> It makes it harder
On Friday, 27 April 2007 23:44, Linus Torvalds wrote:
>
> On Fri, 27 Apr 2007, Rafael J. Wysocki wrote:
> >
> > Why do you think that keeping the user space frozen after 'snapshot' is a
> > bad
> > idea? I think that solves many of the problems you're discussing.
>
> It makes it harder to debu
On Fri, 27 Apr 2007, Rafael J. Wysocki wrote:
>
> Why do you think that keeping the user space frozen after 'snapshot' is a bad
> idea? I think that solves many of the problems you're discussing.
It makes it harder to debug (wouldn't it be *nice* to just ssh in, and do
gdb -p
when s
Hi.
On Fri, 2007-04-27 at 16:55 +0200, Pavel Machek wrote:
> On Fri 2007-04-27 08:41:56, Pekka Enberg wrote:
> > On 4/27/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > >Now, it would be _very_ nice to be able to snapshot system and
> > >continue running, but I just don't see how to do it without
On Friday, 27 April 2007 08:18, Pekka J Enberg wrote:
> On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> > COW is a possibility, but I understood (perhaps wrongly) that Linus was
> > thinking of a single syscall or such like to prepare the snapshot. If
> > you're going to start doing things like this
On Friday, 27 April 2007 06:52, Pekka J Enberg wrote:
> On Thu, 2007-04-26 at 09:56 -0700, Linus Torvalds wrote:
> > >which will map in the snapshot, return the mapped address and the size
> > >(and if you want to support snapshots > 4GB, be my guest, but I
> > > suspect
> > >you're
On Friday, 27 April 2007 14:49, Pavel Machek wrote:
> Hi!
>
> > > * Doing things in the right order? (Prepare the image, then do the
> > > atomic copy, then save).
> >
> > I'd actually like to discuss this a bit..
> >
> > I'm obviously not a huge fan of the whole user/kernel level split and
> >
Am Freitag, 27. April 2007 12:12 schrieb Pekka J Enberg:
> I am talking about snapshot_system() here. It's not given that the
> filesystems need to be read-only (you can snapshot them too). The benefit
> here is that you can do whatever you want with the snapshot (encrypt,
> compress, send over
On Fri 2007-04-27 08:41:56, Pekka Enberg wrote:
> On 4/27/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >Now, it would be _very_ nice to be able to snapshot system and
> >continue running, but I just don't see how to do it without extensive
> >filesystem support.
>
> So what kind of support do we
Hi!
> > * Doing things in the right order? (Prepare the image, then do the
> > atomic copy, then save).
>
> I'd actually like to discuss this a bit..
>
> I'm obviously not a huge fan of the whole user/kernel level split and
> interfaces, but I actually do think that there is *one* split that ma
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Fri, Apr 27, 2007 at 06:50:56AM +1000, Nigel Cunningham wrote:
>
>> I'm perfectly willing to think through some alternate approach if you
>> suggest something or prod my thinking in a new direction, but I'm
>> afraid I just can't see right now how w
On Thu, Apr 26, 2007 at 05:38:07PM -0400, Theodore Tso wrote:
> On Fri, Apr 27, 2007 at 06:08:01AM +1000, Nigel Cunningham wrote:
> > We tried that. It would need some work. IIRC remounting filesystems
> > read-only makes files become marked read-only. Perfectly sensible,
> > except that if you the
Am Freitag, 27. April 2007 08:18 schrieb Pekka J Enberg:
> > No. The snapshot is just that. A snapshot in time. From kernel point of
> > view, it doesn't matter one bit what when you did it or if the state has
> > changed before you resume. It's up to userspace to make sure the user
> > doesn't
Am Freitag, 27. April 2007 08:18 schrieb Pekka J Enberg:
> On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> > COW is a possibility, but I understood (perhaps wrongly) that Linus was
> > thinking of a single syscall or such like to prepare the snapshot. If
> > you're going to start doing things like t
On 4/26/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
In fact, I personally feel that I shouldn't even have merged
userspace-swsusp, but if Andrew thinks it needs to be merged, my personal
feelings simply don't matter that much. I have to trust people. But yes,
as far as *I* am personally concern
On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> User input doesn't account for all system activity. Think of cron jobs
> or user initiated jobs that may have started before the cycle began.
Yes, but the _user_ did not start them so they didn't lose any work. See,
it might or might not be important
Hi.
On Fri, 2007-04-27 at 09:50 +0300, Pekka J Enberg wrote:
> On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> > Sorry Pekka, but that's just broken.
>
> It certainly isn't.
>
> On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> > It implies firstly that we tell all userspace programs "I'm sorry, but
On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> Sorry Pekka, but that's just broken.
It certainly isn't.
On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> It implies firstly that we tell all userspace programs "I'm sorry, but
> I'm suspending at the moment. Can you tip toe quietly around while I do
>
Hi.
On Fri, 2007-04-27 at 09:18 +0300, Pekka J Enberg wrote:
> On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> > COW is a possibility, but I understood (perhaps wrongly) that Linus was
> > thinking of a single syscall or such like to prepare the snapshot. If
> > you're going to start doing things l
On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> > COW is a possibility, but I understood (perhaps wrongly) that Linus was
> > thinking of a single syscall or such like to prepare the snapshot. If
> > you're going to start doing things like this, won't that mean you'd then
> > have to update/redo the
1 - 100 of 135 matches
Mail list logo
