Re: Ext2 bit rot
On 20120326_135131, Stan Hoeppner wrote:
> On 3/26/2012 12:29 PM, Paul E Condon wrote:
>
> > 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.
>
> Start a new thread for this issue. I dunno how to perma-disable tmpfs
> mounted on /tmp. I don't have the time right now. Figuring that out is
> the time consuming part. Once you have that done, you simply create
> /tmp in your root filesystem with appropriate permissions.
>
> drwxrwxrwt 4 root root
>
> > 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.
>
> Don't use slang jargon if you're not familiar with it. ;) Read up on
> "bit rot" and "software rot" so you understand what the OP was referring
> to when he used the term "bit rot". He simply meant that programmers
> may no longer be taking proper care in making sure the EXT2 code is
> maintained to work properly in newer kernels. I disagree with his
> assertion here, but I can foresee a day in the future where his
> sentiments of today may prove correct.
>
> > 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.
>
> For you Paul, there is no compelling reason to switch from EXT3 to
> anything else. Not at this time.
>
> > 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 ( / ) ???
>
> You don't "turn off" tmpfs as it's used by other system functions. You
> simply want to mount /tmp on a different (real) filesystem. As I
> mentioned above, try unmounting /tmp and then creating a /tmp with the
> permissions I mentioned above. Then search for the answer to disabling
> the system level mount of /tmp on tmpfs.
>
> --
> Stan
>
Thanks, Stan.
I had tried to couch my request in the terms that were being used here
without any real understanding of the depths of their inadequacy. I
had already tried to simple mount a spare partition of adequate size
for /tmp, but I got, variously, a response that /tmp was not mounted,
or that it was already mounted. When I tried to umount it, the
response was that it was not mounted. Never that it was busy and
therefore the request should confirmed. Since my last email, a job
that had been running for several days ended, and with that my desire
to do this *without reboot* is gone. I have started trying to
understand what is happening with multiple reboots.
My /etc/fstab is (and always has been from well before I became concerned about ramfs) :
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
LABEL=pla1 / ext3 errors=remount-ro 0 1
# /mpa2 was on /dev/sda2 during installation
UUID=0fde9fde-fe8c-4119-8690-5809cab2fa7c /mpa2 ext3 defaults 0 2
# /mpa3 was on /dev/sda3 during installation
UUID=e3e6afa5-53d8-44cc-b856-e137c56bd11f /mpa3 ext3 defaults 0 2
# /mpb1 was on /dev/sdb1 during installation
UUID=9e1e016e-aea7-4500-bc96-c8d03229c918 /mpb1 ext3 defaults 0 2
# swap was on /dev/sda4 during installation
UUID=c79a09f3-60af-4255-b54f-13a3c40441b7 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
Note that there is no mention of /tmp. This because I want it on the
'root' disk device where it can dynamically share space with /etc,
/boot, /root, etc.
But my 'df' shows:
root@gq:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 56710460 6198380 47631312 12% /
udev 580748 0 580748 0% /dev
tmpfs 116428 676 115752 1% /run
/dev/disk/by-uuid/bdef667c-a248-4cb7-b509-943e28fe0f8f 56710460 6198380 47631312 12% /
tmpfs 5120 0 5120 0% /run/lock
tmpfs 232852 0 232852 0% /tmp
tmpfs 232852 0 232852 0% /run/shm
/dev/sda2 9612516 152684 8971540 2% /mpa2
/dev/sda3 9612516 152684 8971540 2% /mpa3
/dev/sdb1 240365208 52997752 175157532 24% /mpb1
/dev/sde1 480046848 279587324 176074552 62% /media/wdp5
/dev/sdd1 480696480 360827236 95450448 80% /media/wdp6
/dev/sdc1 480040596 142041440 313614496 32% /media/wdp7
/dev/sdf1 480688980 295026152 161245236 65% /media/wdp8
root@gq:~#
which does not appear to me to conform to the above /etc/fstab. I do
have a problem with ramfs in that it has apparently been overlaid on a
reasonable, traditional file system, and interferes with the normal
operation of UNIX 'sort', which defaults to using /tmp for scratch
files. How this came to be the case, is a puzzle to me. The long
thread on how to increase the space allocated to ramfs prompted, plus
your reasonable thinking about why it may not be reasonable, at all,
to use ramfs in some situations, encouraged me to ask how I can free
myself from this nonsensical situation that I am in.
On reboot, all this weird stuff is still present in 'df', but I have
discovered a partial fix. There are in /tmp, a few short files as
follows. It differs from reboot to reboot what is there. On the most
recent reboot, I found:
root@gq:~# ls -l /tmp
total 0
drwx------ 2 root root 40 20120326_181914 pulse-PKdhtXMmr18n
root@gq:~#
This seems to be something left over from starting pulse during
boot. When I delete it, I can umount /tmp, and things start working
more to my liking. This is a real drag. It saves perhaps a few thousand
machine cycles once each reboot, i.e. about once a week at most. And
in return bollixes up a very traditional Debian system. Not a fair
trade-off, IMHO.
And finally, the remnant 'df' after this kludge is:
root@gq:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 56710460 6245884 47583808 12% /
udev 580720 0 580720 0% /dev
tmpfs 116424 664 115760 1% /run
/dev/disk/by-uuid/bdef667c-a248-4cb7-b509-943e28fe0f8f 56710460 6245884 47583808 12% /
tmpfs 5120 0 5120 0% /run/lock
tmpfs 232844 0 232844 0% /run/shm
/dev/sda2 9612516 152684 8971540 2% /mpa2
/dev/sda3 9612516 152684 8971540 2% /mpa3
/dev/sdb1 240365208 52997752 175157532 24% /mpb1
root@gq:~#
Note that there are TWO lines pertaining to '/'. I do not like this. I
think I can live with 'rootfs instead of a proper, on disk device for
'/', but that great long uuid forces me to adjust the width on my
xterm windows and wastes space on my screen and generally annoys me as
an example of reverse progress.
I can live with the '/run/*' being in ram, as doing so will allow me
to continue to describe my system is a plain vanilla Debian/Wheezy
system when asking for help here, but beyond that, I see no advantage,
and a lot of bother each time whatever I do as work-around breaks. So,
I think my desire to 'turn off ramfs' is still a somewhat accurate
description of what I want. I would like to have ramfs made inactive
from before grub starts. It gains me nothing and forces me to use
jargon that I do not understand, etc.
Suggestions?
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: