[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: removing an ext2fs file forces disk activity

From: Jeroen Dekkers
Subject: Re: removing an ext2fs file forces disk activity
Date: Sat, 4 May 2002 23:07:06 +0200
User-agent: Mutt/1.3.28i

On Sat, May 04, 2002 at 01:22:58PM -0700, Thomas Bushnell, BSG wrote:
> Jeroen Dekkers <jeroen@dekkers.cx> writes:
> > I think that for compilation we don't need to synchronize everything
> > to be sure the filesystem the compilation happens on has an
> > inconsistent. It doesn't really matter if you lose some objects
> > files. Maybe it would be a nice thing to provide this as an option.
> The bugs that happen are *not* merely that you lose occasional object
> files.  You can get arbitrary corruption.

And then fsck can repair that in the case of a crash, right?

> In any case, we do not implement bugs deliberately.  We can decide to
> have a totally asynchronous unsafe mode, which is no worse than just
> ignoring this particular issue.

If there is only unimportant data on the filesystem, it would be nice
if it could be faster. I don't see it as a bug, I see it as a
feature. If Linux has the same feature (or bug, whatever you call it)
for years, people probably don't care about it. Hmm, maybe they do
care, with all those journaling filesystems, but I still think it
would be useful to make the tradeoff. 

It would be a lot nicer if glibc would compile a lot faster and have
some filesystem corruption *if* there would be a crash. However, there
should be no crash in the first place.

Jeroen Dekkers
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

Attachment: pgp00jJ7xW3zy.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]