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
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.
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,
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
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
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, 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
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
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
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
18 matches
Mail list logo
