[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: max size of a partition
I sent this to Mark earlier and forgot to cc the list.
Additionally, I have since tried it a second time after
installing a slightly different kernel and going to the
absolute most recent bleeding debian edge with a sid
dist update.
Results are the same within experimental error :-)
Machine locked up while writing inodes in a mkfs, but
this time got further:
host1:/etc/ssh# mkfs -t ext2 /dev/loop0
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2240224 inodes, 4480096 blocks
224004 blocks (5.00%) reserved for the super user
First data block=0
137 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: 120/137
I do not yet have any info on what the final state of
the machine is; it is off in a dusty corner of an NSP
on the other side of town...
--
------------------------------------------------------
Use Linux: A computer Dale Amon, CEO/MD
is a terrible thing Village Networking Ltd
to waste. Belfast, Northern Ireland
------------------------------------------------------
On Tue, Feb 20, 2001 at 01:48:07AM +0000, Marc Mutz wrote:
> pacman wrote:
> >
> > hi,
> > i have problems with the encryption of my partition (28gb). i always get a kernel panic while i create. if the partition has a size of 2gb it works perfectly. so is there a limit of the size? and if, is there a workaround or a solution to solve this problem.
> >
> What kernel version?
> Please describe your setup more _detailed_ (exact commands, entries in
> fstab, you know...)
>
Hot off the presses as it were: I may be having a similar problem.
The 2.4.0 kernel is monolithic and has the 3rd international patch
set applied; I built and installed losetup, mount and umount applying
the o patch set to version q (which applied with offsets).
All of the above were built on a local machine that has developer tools.
The target system does not. (well it has some tools, but they will
eventually be removed as well.)
The losetup worked fine:
losetup -e thecipher /dev/loop0 /dev/md0
Then I started the mkfs:
host1:/etc# mkfs -t ext2 -c -v /dev/loop0
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2240224 inodes, 4480096 blocks
224004 blocks (5.00%) reserved for the super user
First data block=0
137 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Running command: badblocks -b 4096 -s /dev/loop0 4480096
Checking for bad blocks (read-only test): done
Writing inode tables: 10/137
Stopped dead about here...
The raw raid partition /dev/md0 is 18GB with two drives in RAID1
configuration. It was initialized to zero before any of the above
was done.
I had someone check the machine (on the other side of town) and the best I could
was that the console messages said that it tried to kill kernel idle task;
this was followed by a kernel panic.
I realize that doing a loopback crypto on a raw RAID1
might be a bit unusual, but I see no reason it should not
work and it eliminates an unnecessary layer of abstraction
(unless someone can tell me a good reason why I should layer
disks -> raid -> ext2 -> loopback file -> ext2
instead of
disks -> raid -> raw device loopback -> ext2
--
------------------------------------------------------
Use Linux: A computer Dale Amon, CEO/MD
is a terrible thing Village Networking Ltd
to waste. Belfast, Northern Ireland
------------------------------------------------------