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
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 c
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 shoul
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 you
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 a
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
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 eithe
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, 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 loggi
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
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 corrup
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
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 be
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). I
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 p
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 lost
20 matches
Mail list logo
