Re: [debian-knoppix] Recognizing SWAP partitions (incorrectly) and loop inputs
Klaus Knopper wrote:
Hello Stephen,
On Mon, Sep 27, 2004 at 03:52:34PM -0700, Stephen Samuel (leave the email alone) wrote:
I ran into a situation this weekend where I had a disk which
had ONCE been formatted as a Linux SWAP partition and then later
as a BSD filesystem... IT turns out that the bsd newfs program
does NOT stomp on the Linux swap magic string, meaning that when
knoppix booted, it used the new BSD filesystem as a swap partition.
Since the machine in question is low on memory, the swap was
quickly ued, and the filesystem trashed.
That's bad, but I would rather say it's a definitive bug of the bsd newfs
program not to clear a swap signature when creating a file system header!
No. The design of newfs is to NOT delete stuff at the beginning of the partition,
because sometimes other programs (eg. boot loaders ) use it. -- and since various
filesystems have their signatures at various places (eg: Reiserfs is at 64K),
if you took that responsibility, you'd essentially have to zero the entire partition
(or at least the first megabyte).
I originally reported this as a bug to the OpenBSD people (I thought that the
two partition type numbers were the same.. I was wrong).
Linux does not require a swap partition to be of type 82, it can well swap on
any partition or even file / NFS volume that has a valid swap signature. So,
the behaviour you observed was, sorry for your BSD filesystem, IMHO technically
correct: Knoppix just reused a valid swap space on your harddisk.
The reason why partitions have types is to prevent errors like this.
it normally SHOULD NOT occur, unless someone really knows what (s)he's doing.
That's why I tried to add the 'anyswap' boot option -- to allow the current
(dangerous) method. I figure that anybody who's knowledgable enough to create
a swap in a partition with the wrong type should also be geek enough to
read the changelogs and find the documentation for the 'anyswap' option.
Far better than accidently trashing filesystems. I actually considered
modifying the script to check ALL partitions, but swap is the only one
that doesn't have enough other sanity checks to probably recognize when
another filesystem has been formatted on top of it.
I suggest that the best thing to do for this is to check partitions
which exhibit a SWAP signature to verify that they're also LINUX
type partitions... I modified fstype to do this. (see attached diffs).
I will probably add your patches, even that it means that swap partitions other
than type 82 will no longer be detected and used correctly. Most people,
however, DO use type 82 for swap partitions. Thanks.
The other is that I changed the way that input is fed to while
loops.
The construct
while condition ; do
stuff
done << EOF
$( prog )
EOF
seems ineffecient, and obtuse... I'd rather do either:
prog |
while condition ; do
stuff
done
But this forks another subshell (efficiency?), plus, all the variables that are
set within the while loop (which is running in the forked subshell) will be
"forgotten" at the end of that loop. Won't work in many cases. :-(
OOPS You're right. never noticed that.
Both situations fork a subshell (I believe), but the your method forks
off the data creation process while mine forks off the while loop.
Forks and task switches are pretty efficient in Linux -- it was one
of Linus' dogmas in the early days.
or:
while dondition ; do
stuff
done < somefile
The "here" document <<EOF has the advantage of automatic creation and deletion
of the temporary file you created implicitly by $(). That's one reason why I
use it very often in my scripts.
I definitely agree the the here document is better than
actively constructing a temp file. and having to delete it.
I only meant it to be used where the file already exists.
could be seitched to:
[ -r /proc/sys/dev/cdrom/info ] &&
while read drive name cdroms; do
...
done < /proc/sys/dev/cdrom/info
but I'm not sure if the proc file is capable of creating an error
even if the -r test fails.... Is that a real worry?
Caution: Somtimes constructs like
while read variable; do ...; done < /proc/something
just read one or NO line at all, because the shell seems to check the size of
the file to be read incorrectly. I have also observed differences in the result
of $(cat /proc/...) and $(</proc/...) occasionally. I'm not sure if this is a
kernel or bash bug, but it seems that cat is more safe in these cases than
using redirects.
Never seen that, other than one wierd case i just tested -- Where the last line does
not end with a newline, the read won't succeed.
I don't think it would be a kernel bug.. More likely a bash bug. If you can
come up with a test case, it would be a good idea to forward it to the
bash people. Those kinds of constructs seem to be a bit rarer and may
catch them off guard.
I can't see a bug like that being in the kernel without causing other
problems all over the place, but it could easily show up in relatively
rarely used constructs in bash.
You can see the 'no newline' bug/issue here...
-----------------
[tmp]$ echo -n hello |while read line ; do echo $line ; done
[tmp]$ echo hello |while read line ; do echo $line ; done
hello
[tmp]$ while read line ; do echo $line ; done << EOF
> $( echo -n hello )
> EOF
hello
------------------
Might this be what you saw before?
( note: echo -n hello > /tmp/x ; read line < /tmp/x
fails (returns nonzero) but $line gets the value 'hello'
)
I jsut sent a bug report to the bash people on this.
--
Stephen Samuel +1(604)876-0426 samnospam@bcgreen.com
http://www.bcgreen.com/
Powerful committed communication. Transformation touching
the jewel within each person and bringing it to light.
Reply to: