Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian User (http://www.linux-archive.org/debian-user/)
-   -   Ext2 bit rot (was: how to increase space for tmpfs /tmp ... OT question) (http://www.linux-archive.org/debian-user/648850-ext2-bit-rot-how-increase-space-tmpfs-tmp-ot-question.html)

Jochen Spieker 03-26-2012 08:02 AM

Ext2 bit rot (was: how to increase space for tmpfs /tmp ... OT question)
 
Henrique de Moraes Holschuh:
> On Sun, 25 Mar 2012, Paul E Condon wrote:
>>> I'm sure some/many of you will gasp at that fact I still use EXT2. If
>>> it ain't broke, don't "fix" it. The /boot and root filesystems are on
>>> EXT2, with all data storage on XFS. Never had problems with EXT2 in
>>> this setup, so it lives on, for now.
>
> You are, of course, aware of the term "bit rot"?
>
> ext2 is mostly unused nowadays, and it gets little attention and testing.
> It depends heavily on the VFS layer pagecache, and other areas of the kernel
> to work well. But THOSE areas are not staying put. So, ext2 *will* bit
> rot.

I was under the impression that at least ext3 (and maybe even ext4)
shares a lot of code with ext2. Is this wrong?

J.
--
I am no longer prepared to give you the benefit of the doubt.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>

Henrique de Moraes Holschuh 03-26-2012 10:42 AM

Ext2 bit rot (was: how to increase space for tmpfs /tmp ... OT question)
 
On Mon, 26 Mar 2012, Jochen Spieker wrote:
> Henrique de Moraes Holschuh:
> > On Sun, 25 Mar 2012, Paul E Condon wrote:
> >>> I'm sure some/many of you will gasp at that fact I still use EXT2. If
> >>> it ain't broke, don't "fix" it. The /boot and root filesystems are on
> >>> EXT2, with all data storage on XFS. Never had problems with EXT2 in
> >>> this setup, so it lives on, for now.
> >
> > You are, of course, aware of the term "bit rot"?
> >
> > ext2 is mostly unused nowadays, and it gets little attention and testing.
> > It depends heavily on the VFS layer pagecache, and other areas of the kernel
> > to work well. But THOSE areas are not staying put. So, ext2 *will* bit
> > rot.
>
> I was under the impression that at least ext3 (and maybe even ext4)
> shares a lot of code with ext2. Is this wrong?

I am not sure, but it could actually make the bit rot more likely.

People already try hard to not break anything when changing stuff in the
kernel, and update code using old interfaces (otherwise ext2 wouldn't even
build) but corner cases and subtle interactions can get past undetected, and
that's where bit rot starts to set in.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120326104231.GA19862@khazad-dum.debian.net">http://lists.debian.org/20120326104231.GA19862@khazad-dum.debian.net

Paul E Condon 03-26-2012 05:29 PM

Ext2 bit rot (was: how to increase space for tmpfs /tmp ... OT question)
 
On 20120326_074231, Henrique de Moraes Holschuh wrote:
> On Mon, 26 Mar 2012, Jochen Spieker wrote:
> > Henrique de Moraes Holschuh:
> > > On Sun, 25 Mar 2012, Paul E Condon wrote:
> > >>> I'm sure some/many of you will gasp at that fact I still use EXT2. If
> > >>> it ain't broke, don't "fix" it. The /boot and root filesystems are on
> > >>> EXT2, with all data storage on XFS. Never had problems with EXT2 in
> > >>> this setup, so it lives on, for now.
> > >
> > > You are, of course, aware of the term "bit rot"?
> > >
> > > ext2 is mostly unused nowadays, and it gets little attention and testing.
> > > It depends heavily on the VFS layer pagecache, and other areas of the kernel
> > > to work well. But THOSE areas are not staying put. So, ext2 *will* bit
> > > rot.
> >
> > I was under the impression that at least ext3 (and maybe even ext4)
> > shares a lot of code with ext2. Is this wrong?
>
> I am not sure, but it could actually make the bit rot more likely.
>
> People already try hard to not break anything when changing stuff in the
> kernel, and update code using old interfaces (otherwise ext2 wouldn't even
> build) but corner cases and subtle interactions can get past undetected, and
> that's where bit rot starts to set in.
>

Please address my OT question in my OT branch of this
"increase-ramfs-howto" discussion.

How do I turn off ramfs on a wheezy installation on which it is
already there? Preferably without doing a reboot? I am sure ramfs is
doing me no good, but I want to avoid creating new problems by
removing it in a clumsy way.

IMHO, ext3 was introduced in order to correct some bit rot problems in
ext2, as well as to introduce journaling, as such it is not surprising
that it shares a lot of code with ext2. The intention was, I think, to
leave behind the parts of the code that rotted the bits, while
introducing a major new feature. I can imagine that in certain
restricted applications ext2 never executes the part of its code that
rots bits, and as a consequence Stan has never had problems with it.

But I have never had problems with ext3, and all my disks are
formatted in ext3, so I incline toward a path that is the least change
from my present situation. I labeled my post in a way that I hoped
would make it clear that I did not want to engage in the larger (more
interesting???) question of ramfs, in general, and particularly XFS,
which I view as a possible alternative to ext4, to which I have not
yet seen fit to migrate.

So how do I turn off ramfs on a wheezy box where it was installed as
part of the initial net-inst install, and seems to be involved it
the proper functioning of the file system root ( / ) ???

Suggestions?

--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120326172914.GA27678@big.lan.gnu">http://lists.debian.org/20120326172914.GA27678@big.lan.gnu


All times are GMT. The time now is 06:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.