On Mon, Apr 30, 2012 at 11:29 AM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote:
> For starters, use fdisk -u to get 512-byte sector units,
> otherwise it's just inscrutable CHS magic.
>
> i.e.:
>
> # fdisk -lu /dev/sda2
>
> Disk /dev/sda2: 526 MB, 526417920 bytes
> 255 heads, 63 sectors/track, 64 cylinders, total 1028160 sectors
> Units = sectors of 1 * 512 = 512 bytes
>
> so 1028160 512-byte sectors.
>
> # dumpe2fs -h /dev/sda2 | grep "Block count\|Block size"
> dumpe2fs 1.42.2 (27-Mar-2012)
> Block count: 514080
> Block size: 1024
>
> so 514080 1k blocks, or 1028160 512-byte sectors, so bingo, it's full.
Hmm yes, following the same process I can get the same results. I must
have misread/miscalculated something when I looked earlier.
User error :)
> Or, FWIW, it's harmless to invoke resize2fs if the fs already fills the
> partition; it should just exit with a no-op.
Thanks for pointing this out - its probably my best option, coming to
think of it.
>> One easy solution, if possible, would be to find out the number of the
>> last sector used by the filesystem. I could then very easily compare
>> this to the "end" information found in sysfs for the partition. Then I
>> can make the decision on whether to grow or not.
>
> dumpe2fs should certainly be able to tell you. Mounting the fs, and
> doing statfs would, as well (f_blocks). There should also be libext2fs
> functions you could use if you want to do it in C...
Trying the statfs approach (the fs in question is already mounted):
# dumpe2fs -h /dev/mmcblk0p2 | grep "Block count\|Block size"
dumpe2fs 1.42 (29-Nov-2011)
Block count: 949248
Block size: 4096
# stat -f /
File: "/"
ID: f09a7645207bdd68 Namelen: 255 Type: ext2/ext3
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 934935 Free: 198205 Available: 188947
Inodes: Total: 227824 Free: 133103
The numbers don't agree.
(Not a big deal, since I can use the other 2 approaches you mentioned,
just wanted to point it out)
Thanks
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
