Hi!
> >>This adds the ability for the file system to remounted as read only
> >>during a
> >>system suspend. Log the mount points so when the resume occurs, they can
> >>be remounted back to their original states. This is so in an advent of a
> >>power
> >>failure, we try our best to keep
Hi!
This adds the ability for the file system to remounted as read only
during a
system suspend. Log the mount points so when the resume occurs, they can
be remounted back to their original states. This is so in an advent of a
power
failure, we try our best to keep data from being
Hi!
> > Why do you think remounting filesystems is necessary? Are you getting
> > problems with some particular filesystem?
>
> No. But anything in a removable device neets to be either remounted
> read-only or unmounted if that is at all possible, because the user could
> unplug it. It is of
Hi!
Why do you think remounting filesystems is necessary? Are you getting
problems with some particular filesystem?
No. But anything in a removable device neets to be either remounted
read-only or unmounted if that is at all possible, because the user could
unplug it. It is of course,
On Wed 2007-02-07 09:25:39, Henrique de Moraes Holschuh wrote:
> On Wed, 07 Feb 2007, Nigel Cunningham wrote:
> > Ok, as far as usage scenario goes, that's fair enough. But as to the
> > solution, I wonder though whether it's making life more complicated than
> > it needs to be. After all, we
On Wed 2007-02-07 09:25:39, Henrique de Moraes Holschuh wrote:
On Wed, 07 Feb 2007, Nigel Cunningham wrote:
Ok, as far as usage scenario goes, that's fair enough. But as to the
solution, I wonder though whether it's making life more complicated than
it needs to be. After all, we should also
On Wednesday, 7 February 2007 13:05, Henrique de Moraes Holschuh wrote:
> On Wed, 07 Feb 2007, Nigel Cunningham wrote:
> > > We don't cope okay with the power going out, at all. And as an user
> > > case, a
> > > need for fsck if you do something that is a reasonable use case
> > > (unplugging
On Wed, 07 Feb 2007, Nigel Cunningham wrote:
> > We don't cope okay with the power going out, at all. And as an user case, a
> > need for fsck if you do something that is a reasonable use case (unplugging
> > devices while suspended) is not okay, either.
>
> Maybe it depends on the filesystem
Hi.
On Wed, 2007-02-07 at 09:25 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 07 Feb 2007, Nigel Cunningham wrote:
> > Ok, as far as usage scenario goes, that's fair enough. But as to the
> > solution, I wonder though whether it's making life more complicated than
> > it needs to be. After
On Wed, 07 Feb 2007, Nigel Cunningham wrote:
> Ok, as far as usage scenario goes, that's fair enough. But as to the
> solution, I wonder though whether it's making life more complicated than
> it needs to be. After all, we should also be able to cope okay with
> having the power suddenly go out.
On Wed, 07 Feb 2007, Nigel Cunningham wrote:
Ok, as far as usage scenario goes, that's fair enough. But as to the
solution, I wonder though whether it's making life more complicated than
it needs to be. After all, we should also be able to cope okay with
having the power suddenly go out. If we
Hi.
On Wed, 2007-02-07 at 09:25 -0200, Henrique de Moraes Holschuh wrote:
On Wed, 07 Feb 2007, Nigel Cunningham wrote:
Ok, as far as usage scenario goes, that's fair enough. But as to the
solution, I wonder though whether it's making life more complicated than
it needs to be. After all, we
On Wed, 07 Feb 2007, Nigel Cunningham wrote:
We don't cope okay with the power going out, at all. And as an user case, a
need for fsck if you do something that is a reasonable use case (unplugging
devices while suspended) is not okay, either.
Maybe it depends on the filesystem you use.
On Wednesday, 7 February 2007 13:05, Henrique de Moraes Holschuh wrote:
On Wed, 07 Feb 2007, Nigel Cunningham wrote:
We don't cope okay with the power going out, at all. And as an user
case, a
need for fsck if you do something that is a reasonable use case
(unplugging
devices
Hi.
On Tue, 2007-02-06 at 12:32 -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 06 Feb 2007, Nigel Cunningham wrote:
> > Why do you think remounting filesystems is necessary? Are you getting
> > problems with some particular filesystem?
>
> No. But anything in a removable device neets to be
On Tuesday, 6 February 2007 15:32, Henrique de Moraes Holschuh wrote:
> On Tue, 06 Feb 2007, Nigel Cunningham wrote:
> > Why do you think remounting filesystems is necessary? Are you getting
> > problems with some particular filesystem?
>
> No. But anything in a removable device neets to be
On Tue, 06 Feb 2007, Nigel Cunningham wrote:
> Why do you think remounting filesystems is necessary? Are you getting
> problems with some particular filesystem?
No. But anything in a removable device neets to be either remounted
read-only or unmounted if that is at all possible, because the user
On Tue, 06 Feb 2007, Nigel Cunningham wrote:
Why do you think remounting filesystems is necessary? Are you getting
problems with some particular filesystem?
No. But anything in a removable device neets to be either remounted
read-only or unmounted if that is at all possible, because the user
On Tuesday, 6 February 2007 15:32, Henrique de Moraes Holschuh wrote:
On Tue, 06 Feb 2007, Nigel Cunningham wrote:
Why do you think remounting filesystems is necessary? Are you getting
problems with some particular filesystem?
No. But anything in a removable device neets to be either
Hi.
On Tue, 2007-02-06 at 12:32 -0200, Henrique de Moraes Holschuh wrote:
On Tue, 06 Feb 2007, Nigel Cunningham wrote:
Why do you think remounting filesystems is necessary? Are you getting
problems with some particular filesystem?
No. But anything in a removable device neets to be either
On Tue, Feb 06, 2007 at 08:28:33AM +1100, Nigel Cunningham wrote:
> Why do you think remounting filesystems is necessary? Are you getting
> problems with some particular filesystem?
>
> If I recall correctly, we briefly tried remounting filesystems in
> Suspend2, but it created problems with
Hi.
On Fri, 2007-02-02 at 22:35 -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 02 Feb 2007, Andrew Morton wrote:
> > Well the code appears simple enough, but I've not previously heard anyone
> > express a need for this feature. But I know how to cc people who might
> > have heard this.
>
>
On Sat, Feb 03, 2007 at 03:34:57PM -1000, akuster wrote:
> >Can you please explain why this can't be done in userspace?
>
> I am sure it can. The idea came from customer inputs, speed is my
> guess. echo mem > /sys/../state seems a whole lot simpler and cleaner
> than having userspace figure
On Sat, Feb 03, 2007 at 03:34:57PM -1000, akuster wrote:
Can you please explain why this can't be done in userspace?
I am sure it can. The idea came from customer inputs, speed is my
guess. echo mem /sys/../state seems a whole lot simpler and cleaner
than having userspace figure out
Hi.
On Fri, 2007-02-02 at 22:35 -0200, Henrique de Moraes Holschuh wrote:
On Fri, 02 Feb 2007, Andrew Morton wrote:
Well the code appears simple enough, but I've not previously heard anyone
express a need for this feature. But I know how to cc people who might
have heard this.
You are,
On Tue, Feb 06, 2007 at 08:28:33AM +1100, Nigel Cunningham wrote:
Why do you think remounting filesystems is necessary? Are you getting
problems with some particular filesystem?
If I recall correctly, we briefly tried remounting filesystems in
Suspend2, but it created problems with logging -
Christoph Hellwig wrote:
On Fri, Feb 02, 2007 at 01:50:10PM -1000, [EMAIL PROTECTED] wrote:
This adds the ability for the file system to remounted as read only during a
system suspend. Log the mount points so when the resume occurs, they can be
remounted back to their original states. This
Hi!
> This adds the ability for the file system to remounted as read only during a
> system suspend. Log the mount points so when the resume occurs, they can be
> remounted back to their original states. This is so in an advent of a power
> failure, we try our best to keep data from being
On Fri, Feb 02, 2007 at 01:50:10PM -1000, [EMAIL PROTECTED] wrote:
>
>
> This adds the ability for the file system to remounted as read only during a
> system suspend. Log the mount points so when the resume occurs, they can be
> remounted back to their original states. This is so in an advent
On Fri, Feb 02, 2007 at 01:50:10PM -1000, [EMAIL PROTECTED] wrote:
This adds the ability for the file system to remounted as read only during a
system suspend. Log the mount points so when the resume occurs, they can be
remounted back to their original states. This is so in an advent of a
Hi!
This adds the ability for the file system to remounted as read only during a
system suspend. Log the mount points so when the resume occurs, they can be
remounted back to their original states. This is so in an advent of a power
failure, we try our best to keep data from being corrupted
Christoph Hellwig wrote:
On Fri, Feb 02, 2007 at 01:50:10PM -1000, [EMAIL PROTECTED] wrote:
This adds the ability for the file system to remounted as read only during a
system suspend. Log the mount points so when the resume occurs, they can be
remounted back to their original states. This
Andrew Morton wrote:
On Fri, 02 Feb 2007 13:50:10 -1000
[EMAIL PROTECTED] wrote:
+struct suspremount {
+struct super_block *sb;
+struct suspremount *next;
+};
The fields of this struct need a leading tab.
ok.
The name "suspremount" might be unpopular. suspend_remount_state would
On Fri, 02 Feb 2007, Andrew Morton wrote:
> Well the code appears simple enough, but I've not previously heard anyone
> express a need for this feature. But I know how to cc people who might
> have heard this.
You are, now.
We usually try to do it in userspace (and it gets ugly when we fail).
On Fri, 02 Feb 2007 13:50:10 -1000
[EMAIL PROTECTED] wrote:
>
>
> This adds the ability for the file system to remounted as read only during a
> system suspend. Log the mount points so when the resume occurs, they can be
> remounted back to their original states. This is so in an advent of a
This adds the ability for the file system to remounted as read only during a
system suspend. Log the mount points so when the resume occurs, they can be
remounted back to their original states. This is so in an advent of a power
failure, we try our best to keep data from being corrupted or
This adds the ability for the file system to remounted as read only during a
system suspend. Log the mount points so when the resume occurs, they can be
remounted back to their original states. This is so in an advent of a power
failure, we try our best to keep data from being corrupted or
On Fri, 02 Feb 2007 13:50:10 -1000
[EMAIL PROTECTED] wrote:
This adds the ability for the file system to remounted as read only during a
system suspend. Log the mount points so when the resume occurs, they can be
remounted back to their original states. This is so in an advent of a power
On Fri, 02 Feb 2007, Andrew Morton wrote:
Well the code appears simple enough, but I've not previously heard anyone
express a need for this feature. But I know how to cc people who might
have heard this.
You are, now.
We usually try to do it in userspace (and it gets ugly when we fail). If
Andrew Morton wrote:
On Fri, 02 Feb 2007 13:50:10 -1000
[EMAIL PROTECTED] wrote:
snipped
+struct suspremount {
+struct super_block *sb;
+struct suspremount *next;
+};
The fields of this struct need a leading tab.
ok.
The name suspremount might be unpopular. suspend_remount_state
40 matches
Mail list logo
