Bill Davidsen wrote:
I wonder what happens if the device is really read-only and the o/s
tries to replay the journal as part of a r/o mount? I suspect the system
will refuse totally with an i/o error, not what you want.
I exported a ext3 volume via iSCSI, in read-only mode.
It is mounted on
Bill Davidsen wrote:
I wonder what happens if the device is really read-only and the o/s
tries to replay the journal as part of a r/o mount? I suspect the system
will refuse totally with an i/o error, not what you want.
I exported a ext3 volume via iSCSI, in read-only mode.
It is mounted on
Hi!
> >You might not damage the underlying filesystem, but you
> >could sure go
> >off in the weeds trying to read it, if you stumbled
> >upon some
> >half-updated metadata... so while it may be safe for
> >the filesystem, I'm
> >not convinced that it's safe for the host reading the
>
Hi!
You might not damage the underlying filesystem, but you
could sure go
off in the weeds trying to read it, if you stumbled
upon some
half-updated metadata... so while it may be safe for
the filesystem, I'm
not convinced that it's safe for the host reading the
filesystem.
> "BD" == Bill Davidsen <[EMAIL PROTECTED]> writes:
BD> In practice Linux has had lots of practice mounting garbage, and
BD> isn't likely to suffer terminal damage.
These days, with exposed USB ports and automount, it is rather
important that the kernel doesn't suffer terminal damage when
Hi!
> >Distribution installers usually try to probe OSes for
> >building a suited
> >grub menu. Unfortunately, mounting an ext3 partition,
> >even in read-only
> >mode, does perform some operations on the filesystem
> >(log recovery).
> >This is not a good idea since it may silently garbage
Hi!
Distribution installers usually try to probe OSes for
building a suited
grub menu. Unfortunately, mounting an ext3 partition,
even in read-only
mode, does perform some operations on the filesystem
(log recovery).
This is not a good idea since it may silently garbage
data.
BD == Bill Davidsen [EMAIL PROTECTED] writes:
BD In practice Linux has had lots of practice mounting garbage, and
BD isn't likely to suffer terminal damage.
These days, with exposed USB ports and automount, it is rather
important that the kernel doesn't suffer terminal damage when mounting
Eric Sandeen wrote:
Phillip Susi wrote:
Eric Sandeen wrote:
In that case you are mounting the same filesystem uner 2 different
operating systems simultaneously, which is, and always has been, a
recipe for disaster. Flagging the fs as "mounted already" would
probably be a better solution,
Eric Sandeen wrote:
Phillip Susi wrote:
Eric Sandeen wrote:
In that case you are mounting the same filesystem uner 2 different
operating systems simultaneously, which is, and always has been, a
recipe for disaster. Flagging the fs as mounted already would
probably be a better solution,
Eric Sandeen wrote:
except in the case of a journaling filesystem, where the journal in
theory obviates the need for a fsck. (yes, I know... fsck still has a
place...) But, fsck is largely meaningless until the journal has been
recovered anyway (fs can only be consistent if it includes
Phillip Susi wrote:
> Eric Sandeen wrote:
>> It means the filesystem should not be writeable when it is mounted.
>> This is not the same as saying that the filesystem itself should do no
>> IO in the course of making that read-only mount available.
>
> I disagree.
>
>> I respectfully disagree,
Eric Sandeen wrote:
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the filesystem itself should do no
IO in the course of making that read-only mount available.
I disagree.
I respectfully disagree, see above.
Based on what? I argue
On Tue, Apr 10, 2007 at 02:08:26PM +0200, Jörn Engel wrote:
> On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
> >
> > I suppose what you could do is to read in the journal, and use it to
> > create an remapping table so that when you want to read block #5126,
> > and block number 5126
On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
>
> I suppose what you could do is to read in the journal, and use it to
> create an remapping table so that when you want to read block #5126,
> and block number 5126 is in the journal, to read the journal version
> of the block instead
On Tue, Apr 10, 2007 at 09:22:53AM +0200, Jörn Engel wrote:
> > Under all conditions it should be safe to mount a read-only block
> > device, but that is not the same as mounting a filesystem read-only.
>
> In particular, it is a lame excuse when this claim is true. If the
> block-device is
On Mon, 9 April 2007 12:21:15 -0500, Eric Sandeen wrote:
> Phillip Susi wrote:
> >
> > When the filesystem is told to mount the disk read only, that means it
> > should not write to it.
>
> It means the filesystem should not be writeable when it is mounted.
> This is not the same as saying
On Mon, 9 April 2007 12:21:15 -0500, Eric Sandeen wrote:
Phillip Susi wrote:
When the filesystem is told to mount the disk read only, that means it
should not write to it.
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the
On Tue, Apr 10, 2007 at 09:22:53AM +0200, Jörn Engel wrote:
Under all conditions it should be safe to mount a read-only block
device, but that is not the same as mounting a filesystem read-only.
In particular, it is a lame excuse when this claim is true. If the
block-device is read-only,
On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
I suppose what you could do is to read in the journal, and use it to
create an remapping table so that when you want to read block #5126,
and block number 5126 is in the journal, to read the journal version
of the block instead of the
On Tue, Apr 10, 2007 at 02:08:26PM +0200, Jörn Engel wrote:
On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
I suppose what you could do is to read in the journal, and use it to
create an remapping table so that when you want to read block #5126,
and block number 5126 is in the
Eric Sandeen wrote:
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the filesystem itself should do no
IO in the course of making that read-only mount available.
I disagree.
I respectfully disagree, see above.
Based on what? I argue
Phillip Susi wrote:
Eric Sandeen wrote:
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the filesystem itself should do no
IO in the course of making that read-only mount available.
I disagree.
I respectfully disagree, see above.
Eric Sandeen wrote:
except in the case of a journaling filesystem, where the journal in
theory obviates the need for a fsck. (yes, I know... fsck still has a
place...) But, fsck is largely meaningless until the journal has been
recovered anyway (fs can only be consistent if it includes
Phillip Susi wrote:
> Samuel Thibault wrote:
>> Hi,
>>
>> Distribution installers usually try to probe OSes for building a suited
>> grub menu. Unfortunately, mounting an ext3 partition, even in read-only
>> mode, does perform some operations on the filesystem (log recovery).
>> This is not a
On Apr 8 2007 22:24, Eric Sandeen wrote:
> Samuel Thibault wrote:
>
> Can you elaborate? Under what circumstances is log replay going to harm data?
> Do you mean that the installer mounts partitions, looking for what OS is
> installed? How is that harmful?
>
> Hm, so the root cause there seems
On Apr 09, 2007, at 11:43:15, Phillip Susi wrote:
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a
suited grub menu. Unfortunately, mounting an ext3 partition, even
in read-only mode, does perform some operations on the filesystem
(log
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage
On Sun, Apr 08, 2007 at 10:42:03PM -0500, Eric Sandeen wrote:
> Samuel Thibault wrote:
>
> >>Hm, so the root cause there seems that the installer found 2 legs of a
> >>mirror and mounted them independently, recovering them independently...
> >>But why did that cause problems?
> >
> >Because
On Sun, 08 Apr 2007 22:24:50 CDT, Eric Sandeen said:
> Can you elaborate? Under what circumstances is log replay going to harm
> data? Do you mean that the installer mounts partitions, looking for
> what OS is installed? How is that harmful?
Another usage case that really wants to avoid the
On Apr 08, 2007 22:24 -0500, Eric Sandeen wrote:
> Samuel Thibault wrote:
> >Distribution installers usually try to probe OSes for building a suited
> >grub menu. Unfortunately, mounting an ext3 partition, even in read-only
> >mode, does perform some operations on the filesystem (log recovery).
On Apr 08, 2007 22:24 -0500, Eric Sandeen wrote:
Samuel Thibault wrote:
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This
On Sun, 08 Apr 2007 22:24:50 CDT, Eric Sandeen said:
Can you elaborate? Under what circumstances is log replay going to harm
data? Do you mean that the installer mounts partitions, looking for
what OS is installed? How is that harmful?
Another usage case that really wants to avoid the log
On Sun, Apr 08, 2007 at 10:42:03PM -0500, Eric Sandeen wrote:
Samuel Thibault wrote:
Hm, so the root cause there seems that the installer found 2 legs of a
mirror and mounted them independently, recovering them independently...
But why did that cause problems?
Because that thrashed his
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage
On Apr 09, 2007, at 11:43:15, Phillip Susi wrote:
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a
suited grub menu. Unfortunately, mounting an ext3 partition, even
in read-only mode, does perform some operations on the filesystem
(log
On Apr 8 2007 22:24, Eric Sandeen wrote:
Samuel Thibault wrote:
Can you elaborate? Under what circumstances is log replay going to harm data?
Do you mean that the installer mounts partitions, looking for what OS is
installed? How is that harmful?
Hm, so the root cause there seems that
Phillip Susi wrote:
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since
Eric Sandeen wrote:
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it
Samuel Thibault wrote:
Hm, so the root cause there seems that the installer found 2 legs of a
mirror and mounted them independently, recovering them independently...
But why did that cause problems?
Because that thrashed his data (or at least it didn't help to keep data
safe).
Other
Eric Sandeen, le Sun 08 Apr 2007 22:24:50 -0500, a écrit :
> Samuel Thibault wrote:
> >Distribution installers usually try to probe OSes for building a suited
> >grub menu. Unfortunately, mounting an ext3 partition, even in read-only
> >mode, does perform some operations on the filesystem (log
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage data. XFS has a
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage data. XFS has a
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage
Eric Sandeen, le Sun 08 Apr 2007 22:24:50 -0500, a écrit :
Samuel Thibault wrote:
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log
Samuel Thibault wrote:
Hm, so the root cause there seems that the installer found 2 legs of a
mirror and mounted them independently, recovering them independently...
But why did that cause problems?
Because that thrashed his data (or at least it didn't help to keep data
safe).
Other
Eric Sandeen wrote:
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it
48 matches
Mail list logo