Skip to contentSkip to conversation

Can't mke2fs lv

linux-lvm Marc MERLIN 4 participants 5 messages Feb 11, 2002

lore
Share & tools
lore

Marc MERLIN

author
#0 lore raw

I've never had this problem before, it's on a 2.4.14 kernel with lvm 1.0.1rc4:

gargamel:~# lvscan 
lvscan -- ACTIVE            "/dev/BootMylexLVM/usr" [1.50 GB]
lvscan -- ACTIVE            "/dev/BootMylexLVM/var" [2.00 GB]
lvscan -- ACTIVE            "/dev/BootMylexLVM/home" [115.00 GB]
lvscan -- 3 logical volumes with 118.50 GB total in 1 volume group
lvscan -- 3 active logical volume

I was able to mke2fs /dev/BootMylexLVM/usr just fine. However, doing var and home fails like this:

gargamel:~# mke2fs  /dev/BootMylexLVM/var 
mke2fs 1.25 (20-Sep-2001)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
262144 inodes, 524288 blocks
26214 blocks (5.00%) reserved for the super user
First data block=0
16 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912

mke2fs: Attempt to write block from filesystem resulted in short write zeroing block 524280 at end of filesystem

gargamel:~# mke2fs  /dev/BootMylexLVM/home
mke2fs 1.25 (20-Sep-2001)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
15073280 inodes, 30146560 blocks
1507328 blocks (5.00%) reserved for the super user
First data block=0
920 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872

File size limit exceeded

Did I do something stupid, or do I need to upgrade?
(I did do a quick search on this kind of failure, but didn't find anything)

Details on the VG:

gargamel:~# vgdisplay  -v
--- Volume group ---
VG Name               BootMylexLVM
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                255
Cur LV                3
Open LV               0
MAX LV Size           1023.97 GB
Max PV                255
Cur PV                1
Act PV                1
VG Size               135.94 GB
PE Size               16.00 MB
Total PE              8700
Alloc PE / Size       7584 / 118.50 GB
Free  PE / Size       1116 / 17.44 GB
VG UUID               opNV4o-2l8K-Vdtg-aUBK-c2uT-FbA7-BZFvJx

--- Logical volume ---

LV Name                /dev/BootMylexLVM/usr
VG Name                BootMylexLVM
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                1.50 GB
Current LE             96
Allocated LE           96
Allocation             next free
Read ahead sectors     120
Block device           58:0

--- Logical volume ---

LV Name                /dev/BootMylexLVM/var
VG Name                BootMylexLVM
LV Write Access        read/write
LV Status              available
LV #                   2
# open                 0
LV Size                2.00 GB
Current LE             128
Allocated LE           128
Allocation             next free
Read ahead sectors     120
Block device           58:1

--- Logical volume ---

LV Name                /dev/BootMylexLVM/home
VG Name                BootMylexLVM
LV Write Access        read/write
LV Status              available
LV #                   3
# open                 0
LV Size                115.00 GB
Current LE             7360
Allocated LE           7360
Allocation             next free
Read ahead sectors     120
Block device           58:2

--- Physical volumes ---

PV Name (#)           /dev/rd/disc0/part5 (1)
PV Status             available / allocatable
Total PE / Free PE    8700 / 1116

Thanks,
Marc

Signature · 4 lines
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger [email protected] for PGP key
#1 lore raw
Quoted 8 lines · Marc MERLIN

I've never had this problem before, it's on a 2.4.14 kernel with lvm 1.0.1rc4:

gargamel:~# lvscan 
lvscan -- ACTIVE            "/dev/BootMylexLVM/usr" [1.50 GB]
lvscan -- ACTIVE            "/dev/BootMylexLVM/var" [2.00 GB]
lvscan -- ACTIVE            "/dev/BootMylexLVM/home" [115.00 GB]
lvscan -- 3 logical volumes with 118.50 GB total in 1 volume group

<SNIP>

Quoted 7 lines
        4096000, 7962624, 11239424, 20480000, 23887872

File size limit exceeded

Did I do something stupid, or do I need to upgrade?
(I did do a quick search on this kind of failure, but didn't find anything)

No, there's an OS bug related to the 2 GB file size limit which causes both your problems. You must be directly logged in as 'root', *no* 'su root' in order to run the commands fine.

Quoted 6 lines

Details on the VG:

gargamel:~# vgdisplay  -v
--- Volume group ---
VG Name               BootMylexLVM

<SNIP>

Quoted 17 lines

PV Status available / allocatable
Total PE / Free PE 8700 / 1116

Thanks,
Marc

Signature · 10 lines
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger [email protected] for PGP key

_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Signature · 15 lines
Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
[email protected]                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#2 lore raw
Quoted 15 lines · Heinz J . Mauelshagen
Quoted 8 lines · Marc MERLIN

I've never had this problem before, it's on a 2.4.14 kernel with lvm 1.0.1rc4:

gargamel:~# lvscan 
lvscan -- ACTIVE            "/dev/BootMylexLVM/usr" [1.50 GB]
lvscan -- ACTIVE            "/dev/BootMylexLVM/var" [2.00 GB]
lvscan -- ACTIVE            "/dev/BootMylexLVM/home" [115.00 GB]
lvscan -- 3 logical volumes with 118.50 GB total in 1 volume group

<SNIP>

Quoted 5 lines
        4096000, 7962624, 11239424, 20480000, 23887872

File size limit exceeded

Quoted 6 lines
Quoted 2 lines

Did I do something stupid, or do I need to upgrade?
(I did do a quick search on this kind of failure, but didn't find anything)

No, there's an OS bug related to the 2 GB file size limit which causes both your problems. You must be directly logged in as 'root', *no* 'su root' in order to run the commands fine.

Mmmh, interesting.

Unfortunately, that's not it, the machine doens't have any users, and I ssh'ed in as root

gargamel:~# id
uid=0(root) gid=0(root) groups=0(root)
gargamel:~#  mke2fs  /dev/BootMylexLVM/var
mke2fs 1.25 (20-Sep-2001)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
262144 inodes, 524288 blocks
26214 blocks (5.00%) reserved for the super user
First data block=0
16 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912

mke2fs: Attempt to write block from filesystem resulted in short write zeroing block 524280 at end of filesystem

Since I suspected the 2G file limit (although it didn't make any sense), I've made sure I have a recent libc.

gargamel:~# ldd /sbin/mke2fs 
        libext2fs.so.2 => /lib/libext2fs.so.2 (0x49874000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x49888000)
        libe2p.so.2 => /lib/libe2p.so.2 (0x4988b000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x49890000)
        libc.so.6 => /lib/libc.so.6 (0x49893000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x49858000)
gargamel:~# l /lib/libc.so.6     
lrwxrwxrwx    1 root     root           13 Feb 11 09:21 /lib/libc.so.6 -> libc-2.2.5.so*

Is the bug at mke2fs time, or before that, when the vg/lvs are created? Do I want to switch e2fsprogs (I already have 1.25), libcs, lvm tools, or kernels?

Thanks,
Marc

Signature · 4 lines
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger [email protected] for PGP key
#3 lore raw
Quoted 9 lines · Marc MERLIN
Quoted 3 lines · Heinz J . Mauelshagen

No, there's an OS bug related to the 2 GB file size limit which causes both your problems. You must be directly logged in as 'root', *no* 'su root' in order to run the commands fine.

Mmmh, interesting.

Unfortunately, that's not it, the machine doens't have any users, and I ssh'ed in as root

It could still be that the ssh process inherits the ulimit from its parent. The real problem with this bug is that "ulimit -f" returns "unlimited", but in fact it is really 2GB. The user tools think 2GB is unlimited, but the kernel thinks 4GB is unlimited. This assumes you don't have a ulimit set at some value less than 2GB.

Quoted 1 line

I've never had this problem before, it's on a 2.4.14 kernel with lvm

The problem existed between 2.4.10 and 2.4.18-pre somthing I think. It was a result of 2.4.10 moving block devices into the page cache, which treated them like regular files, and ulimit applies to regular files.

Quoted 1 line

mke2fs 1.25 (20-Sep-2001)

If you have e2fsprogs 1.26, it should have a fix for this problem (it tries to set the ulimit to 4GB instead of 2GB for you). Please let me know if this fixes your problem. Note that this workaround will only fix programs in e2fsprogs not any other tool which tries to read from a raw device (dump or dd or pvmove perhaps).

I _thought_ that glibc-2.2 was not affected by this problem, but it could be that if you have an old shell which uses the old getrlimit syscall it will still break your system.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

author
#4 lore raw
Quoted 8 lines · Andreas Dilger
Quoted 2 lines

Unfortunately, that's not it, the machine doens't have any users, and I ssh'ed in as root

It could still be that the ssh process inherits the ulimit from its parent. The real problem with this bug is that "ulimit -f" returns "unlimited", but in fact it is really 2GB. The user tools think 2GB is unlimited, but the kernel thinks 4GB is unlimited. This assumes you don't have a ulimit set at some value less than 2GB.

Well, I didn't set the ulimit, but sure enough, something did. After upgrading from bash 2.04 to bash 2.05 and from ssh 2.5.x to 3.0.x, I got:

gargamel:~# ulimit -f
2097151

I am not setting this in /etc/security/limits.conf, so something else probably is.

Either way, after

gargamel:~# ulimit -f unlimited
it works like a charm
Quoted 3 lines

I _thought_ that glibc-2.2 was not affected by this problem, but it could be that if you have an old shell which uses the old getrlimit syscall it will still break your system.

I don't know if bash 2.05 is considered old or not, but it's true that the ulimit could be set by anything along the chain.

I haven't upgraded e2fsprogs yet, but if it tries to reset the filesize limit to unlimited, it would definitely fix the problem I had.

Anyway, it's all working now.

Thanks a lot,
Marc

Signature · 4 lines
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger [email protected] for PGP key