On Thu, Apr 21, 2016 at 2:25 PM, Gordon Messmer
<gordon.messmer(a)gmail.com> wrote:
On 04/21/2016 10:08 AM, Weiner, Michael wrote:
>>
>> mkfs.ext3 -F -b 4096 -n /dev/sdb1
>> >Note that I don't have a CentOS 5 system around for testing, and I
don't
>> > know what mixing -F and -n does.
>
> Yeah I was a little nervous about that, and as such, I didn’t try it:)
> because the flags are also counter to one another.
Nonetheless, if you created a 15TB ext3 filesystem using the vendor's tools,
you would have *had* to use "-F -b 4096". You're not going to locate
superblock backups using any other set of arguments.
If you have the exact size of this 15T volume, the exact number of
sectors I mean. Then it's not difficult to create either a qcow2 file
or a virtual sized thinp LV and then run the format command on it. You
still want to use -n and hopefully that inhibits actual creation, and
that's because ext3 or ext4 on a 15TB volume produces a massive amount
of preallocated metadata, gigabytes. So if this is thinly provisioned,
the metadata itself writing to disk could blow up the backing. And
also it'll take a long time even if it doesn't blow up. LVM thinp is
new so you can't do this on CentOS 5 but you can at least get the
superblock numbers and see if any of those coincide with your actual
filesystem.
Example:
# vgs
VG #PV #LV #SN Attr VSize VFree
VG 1 1 0 wz--n- 180.00g 89.82g
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log
Cpy%Sync Convert
thintastic VG twi-aotz-- 90.00g 0.00 0.42
lvcreate -V 15T -T VG/thintastic -n bigassfs
WARNING: Sum of all thin volume sizes (15.00 TiB) exceeds the size
of thin pool VG/thintastic and the size of whole volume group (180.00
GiB)!
For thin pool auto extension
activation/thin_pool_autoextend_threshold should be below 100.
Logical volume "bigassfs" created.
# lvs
LV VG Attr LSize Pool Origin Data% Meta%
Move Log Cpy%Sync Convert
bigassfs VG Vwi-a-tz-- 15.00t thintastic 0.00
thintastic VG twi-aotz-- 90.00g 0.00 0.43
# mkfs.ext3 -n /dev/VG/bigassfs
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 4026531840 4k blocks and 503316480 inodes
Filesystem UUID: 9806224b-3702-4b07-9a76-58e5a12b4bf9
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
2560000000, 3855122432
# mkfs.ext3 -n -F -b 4096 /dev/VG/bigassfs
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 4026531840 4k blocks and 503316480 inodes
Filesystem UUID: 40dc3b6e-96fe-411b-9cfb-292bc62090f1
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
2560000000, 3855122432
So it's the same result, no fs is created. But you're using a much
older version of e2fsprogs so you probably don't want to take a change
that -F works differently on the actual file system or you'll totally
nerf it.
If your volume is really exactly 15.00TiB, that's what the above super
blocks are based on.
# lvs --units s
LV VG Attr LSize Pool Origin Data%
Meta% Move Log Cpy%Sync Convert
bigassfs VG Vwi-a-tz-- 32212254720S thintastic 0.00
thintastic VG twi-aotz-- 188735488S 0.00 0.43
Even that agrees down to the 512 byte sector. And lvcreate -V accepts
s for units as well. So once you get sectors for your storage block
device, you can create a virtual one with -V xxxxs
--
Chris Murphy