On Mon, 2006-02-13 at 16:27 -0500, Mark Haney wrote: > Robert Locke wrote: > > On Mon, 2006-02-13 at 08:22 -0500, Mark Haney wrote: > > > >> Robert Locke wrote: > >> > >>>> > >>>> > >>> OK, so lvdisplay showing the full amount is good, so the underlying > >>> virtual partition is 6.36TB.... Now the tune2fs I was suggesting was > >>> simply the -l option that would dump the ext2/3 superblock. We should > >>> be able to see the "block count" and the "block size" which when > >>> multiplied should be 6.36TB. Since you are at least on a 2.6 kernel, I > >>> don't think we have the 2TB filesystem limit, though I don't remember > >>> when that got bumped up to 32.... > >>> > >>> --Rob > >>> > >>> > >>> > >> I hate to be a complete idiot, but I can't get tune2fs to work on the > >> lv, I must be doing something wrong. Can you use tune2fs on an lvm volume? > >> > >> > > > > <big grin> > > > > Should just be "tune2fs -l /dev/vgname/lvname". So try: > > > > tune2fs -l /dev/Volume02/Volume02lv > > tune2fs -l /dev/Volume03/Volume03lv > > > > That should generate about a page of each.... > > > > --Rob > > > > > I just got time to actually figure that out. I'm not a complete > imbecile, I swear. Here's the output of one 6.36TB array: > > ilesystem volume name: <none> > Last mounted on: <not available> > Filesystem UUID: d775f424-2a12-44ac-9260-c00013f963ee > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal filetype needs_recovery > sparse_super large_file > Default mount options: (none) > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 316325888 > Block count: 632648704 > Reserved block count: 31632435 > Free blocks: 622713507 > Free inodes: 316325877 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 16384 > Inode blocks per group: 512 > Filesystem created: Thu Jan 5 13:41:11 2006 > Last mount time: Mon Feb 13 14:06:06 2006 > Last write time: Mon Feb 13 14:06:06 2006 > Mount count: 2 > Maximum mount count: 31 > Last checked: Thu Jan 5 13:41:11 2006 > Check interval: 15552000 (6 months) > Next check after: Tue Jul 4 14:41:11 2006 > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 128 > Journal inode: 8 > Default directory hash: tea > Directory Hash Seed: 62d0ad33-5300-481b-8620-bbdb6fd30a5b > Journal backup: inode blocks > Well, now we're in the not so good news.... Just doing the math.... (Block count * Block size) / 1024^4 (632648704 * 4096) / 1024^4 = 2.35 TB So, what you are seeing in df is accurate as far as the filesystem is concerned.... So, my thoughts are that perhaps someone originally created the logical volumes at 2.4TB, created the filesystems, and then tried to extend the logical volumes with lvextend? Of course, while lvextend will grow the underlying logical volume it does not grow the filesystem. That is done with the ext2online command, if the filesystem is mounted, and with resize2fs if the filesystem is unmounted. Can you check to see which of those two utilities you have available in FC2? Whether you have both resize2fs and ext2online? Of course, resizing the filesystem is potentially dangerous and presumes good quality backups, and read, lots of disclaimers at this point about eating your data for lunch...... --Rob
