Newsgroups: comp.os.linux Date: 2002-03-01 13:17:20 PST
Newsgroups: comp.os.linux Date: 2002-03-01 13:17:20 PST
> Q1: Is the format of a floppy used in Linux ext2? i.e., is there a > 'standard' format for floppies in Linux and does it vary by distro?
There is no standard. A floppy is a disk, and it has whatever filesystem its creator wants it to have. If you create the filesystem, you can do:
mkfs -t ext2 /dev/fd0
to make a Second Extended (ext2) filesystem, or:
mkdosfs -F 32 /dev/fd0
to make a FAT32 filesystem.
> Q2: When you make a rescue disk, does it use the 'standard' Linux format or > a different 'special' one?
I can't answer this one, but I have seen rescue disks that had no filesystems on them (just a boot loader in the MBR and a kernel right behind it). In such a case, the floppy cannot be mounted (merely booted from).
> Q3: The prompts in Linux will sometimes say to insert a 'formatted floppy' > prior to writing something for you. Do they mean an MS-DOS format or an > ext2 format?
Either kind, I suspect. They want to mount it to write files on it, and the mount command will auto-detect the kind of filesystem on it.
> Q4: I tried the 'mkfs -t ext2 /dev/fd0' command to make a floppy into an > ext2 disk and it seems to work. HOWEVER, the surprising and disconcerting > thing about it was that the command execution took all of about 5 seconds. > There was no track-by-track formatting or verification of tracks/blocks > across the entire disk. Is this normal?
Yes. mkfs writes very little data to the floppy to create an ext2 filesystem. It does not verify the integrity of the floppy (not its job).
> How can I verify media with an FDD
You can do this (but it destroys all data on the floppy):
# dd if=/dev/urandom of=/tmp/fdtest bs=1024 count=1440 # md5sum -b /tmp/fdtest [remember the output of this command] # dd if=/tmp/fdtest of=/dev/fd0 # dd if=/dev/fd0 | md5sum -b [compare this output the the above output]
If the outputs of the two md5sum commands are the same (and no "I/O error" is reported by dd, then the floppy is OK (for now).
Francis Litterio
October 12, 2005 Posted by ubuntonista in ubuntu, administration, applications. trackback
Ubuntu forces drives to be checked once for every 30 times the filesystem is mounted. This means that on an average, once every 30 times you bootup your computer, the filesystem integrity is checked. This is very reasonable for a desktop, which is seldom rebooted. However, for a laptop, this means pain, since you may be planning on making a presentation, and Ubuntu may start a filesystem check just when you hook up your laptop to the projector and bootup! Today we will see how to disable (or force) the checking temporarily, and also how to adjust the period and frequency of the check.
To disable filesystem integrity check for the next bootup, create a file called /fastboot. So a
$sudo touch /fastboot
will disable filesystem check for the next time you bootup. Since the /fastboot file is removed during bootup, this will disable filesystem check only once - for the one time you bootup after you create the /fastboot file (which need not have anything in it — hence the touch, which only creates the file)
On the contrary to force a filesystem check the next time you bootup, create a file called /forcefsck by doing
$sudo touch /forcefsck
Now, on to the more interesting business of how to change the number of bootups between filesystem checks, and modifying the period with which the filesystem is checked. The following applies to ext2 and ext3 filesystems.
tune2fs is an utility that you can use to change both the number of bootups between filesystem checks, and the number of days/weeks/months between filesystem checks.
For example to have the filesystem checked once every 60 bootups use $sudo tune2fs -c 60
To have the filesystem check run periodically, say once a week, use
$sudo tune2fs -i 1w
changing the "w" to "d" or "m" will have the check run once daily and once monthly - you get the idea.
Newsgroups: comp.os.linux.setup,comp.os.linux.misc Date: Tue, 7 Jan 2003 11:01:17 -0500
> > Just curious, why do I need a /initrd/ directory? As it's empty after > > bootup, I removed it and boo! the system won't boot - kernel panic. It > > took me some sweat to figure this out and repair it. > > I beleive it is a mount point for your initrd image file (.img) which is > needed for your kernel to boot.
This is correct. It was quite fun correcting this on a rarely rebooted system: a few months elapsed between the time that I removed the directory and the next time I rebooted.
Ed
$ chattr --version chattr 1.18.7, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
$ lsattr [...] ----------- - - doc ----------- - - weka ----------- - - weka-src [...]
$chattr -R +c doc [...] --c-------- 32 gzip9 doc [...]
$ cd doc $ lsattr --c----B--- 32 gzip9 AllNames.html --c-------- 32 gzip9 Package-weka.associations.html
DESCRIPTION
chattr changes the file attributes on a Linux second extended file system.
The format of a symbolic mode is +-=[ABDESXacdisu].
(c) compressed
The `B' (file contains compressed clusters) and `D' (file has some clusters needing compression) flags are accepted but ignored. These flags cannot be changed from user space.
OPTIONS
-R Recursively change attributes of directories and their con-
tents. Symbolic links encountered during recursive directory
traversals are ignored.
-V Be verbose with chattr's output and print the program version.
-m compression_method
Set the algorithm used for compression. Currently, the only
supported algorithms are `bzip2', `lzv1', `lzrw3a' and
`gzip1', `gzip2', ..., `gzip9' where the number is equivalent
to the compression level used for gzip.
A file with the `c' attribute set is automatically compressed on the disk by the kernel. A read from this file returns uncompressed data. A write to this file is followed by an attempt to compress the data written.
Directories can also be marked with the `c' attribute; in such a case, nothing is compressed, but any newly created file in the direc- tory will automatically be marked with the `c' attribute. Similarly, a directory can be given an algorithm name and/or cluster size, so that newly created files will use this algorithm / cluster size. New files in the directory will only inherit the flags if they get a new inode, not if they are simply given a new link in that directory (e.g. with `mv' or `ln').
*References*: please refer to cmd:e2compr topic in disk tools section in TuGnrl.doc for general info.
Generally, not going to use it for the following reasons:
If you are an existing e2compr user, you might as well wait a bit before switching to 0.4
You must enable CONFIG_EXPERIMENTAL in your kernel config in order to use e2compr. (This is in preparation for integration into standard kernel.)
There is no e2compress program for 0.4.x yet.
The author has more chance to smoothen the transition from 0.3.x to 0.4.x.
`e2compress' is just another way of achieving `chattr +c' (or `chattr -c). Unlike `chattr +c', `e2compress' creates a new file for the compressed file, deleting the original once the compression has been verified. The advantage of this is that the newly created file needn't be fragmented. (You may also consider it an advantage that the transformation is verified.) It should also be safer in the case that your machine is switched off (etc.) part way through compression (because the original file should still be on on the hard disk). Another difference from `chattr +c' is that the compression occurs in user space rather than kernel space. The disadvantage is that you need to have space on your hard disk for both to exist simultaneously.
Problem: Kernel patches is only for linux-2.1.
e2compr patch for kernel 2.1.93 and above. Yes, this really is the most recent kernel I've released a 0.3 patch against. So far no-one's complained;
I think most/all people who use 2.1 (or 2.2) kernels have switched to e2compr-0.4. If do want to use e2compr-0.3.x with Linux 2.2, then say so, though you should consider switching to e2compr-0.4.x, which fixes a couple of bugs.
should use 0.4.x. Patch & recompile the kernal!
Be extremely careful when using it. Normal disk tools can't recognize it.
documented on: 2000.10.11 Wed 12:17:02
>I found that my Redhat6.2 tries to access my hard drive about every 5 >seconds. I'm using a 256M RAM P3 with 1G swap, So I am really curious >why redhat access my HD so often.
Check cron jobs. Check how much memory is actually in use. Having a big swap file won't reduce access to the Hard Drive, as the swap is on the hard drive to begin with.
Fester
While your system does do various logging and flushing to disk, you might see your drive light go on frequently when some program is simply checking the cdrom to see if anything changed.
For example if you are running Gnome I think it is 'magicdev' that checks the cdrom. In Settings/Peripherals/CD Properties you can control if or what it automatically does. KDE may have something similar.
David Efflandt
documented on: 2000.10.12 Thu 14:34:18
Newsgroups: comp.os.linux.misc >I was just wondering, if there's such a thing as "disk defragmenter" in >linux, or something similar to windows', "disk defragmenter"
Yes, but you don't need it and it can seriously mess up your filesystem. The ext2 filesystem that Linux uses was designed a bit more intelligently than FAT, and does not suffer nearly as badly from file fragmentation. This question crops up every so often; it tends to lead to people yelling at each other. Go to http://deja.com/home_ps.shtml , search comp.os.linux.misc for "fragmentation", and you'll find a number of threads discussing this very topic. HTH,
Matt G
documented on: 2000.10.25 Wed 21:51:01