0

I am trying to automatically determine the size of a ext2 ramdisk filesystem that a directory will make. What I am currently doing is:

BLOCK_COUNT=`du $RAMDISK_FS_DIR| tail -1 |awk '{print $1}'

dd if=/dev/zero of=ramdisk.img bs=1024 count=$BLOCK_COUNT
mke2fs -F ramdisk.img -L "ramdisk" -b 1024 -m 0
tune2fs ramdisk.img -i 0

But when I mount and cp -r $RAMDISK_FS_DIR into ramdisk.img i get messages like these

cp: cannot create directory `ramdisk/var/www': No space left on device

I determined that in my this specific case increasing BLOCK_COUNT by 48 blocks is exactly how much I need for the operation to succeed. I need a way to find this number for arbitrary directory sizes.

Note that my host filesystem is ext4.

fakedrake
  • 6,528
  • 8
  • 41
  • 64

1 Answers1

2

I don't think there's a good way to do this in general. In general, superblocks, inode tables, block bitmaps, and various other structures in the filesystem will vary in size depending on exactly how big the filesystem is and what's in it. Even the space occupied by files (as computed by du) may not be the same on the source filesystem as on the destination filesystem.

I wonder why you are trying to make a filesystem with a size exactly equal to its contents. Since this filesystem will always be full after it is built, you can't add anything to it (unless you delete stuff first), which makes me think it might be intended to be read-only. Buy if it's read-only, why don't you use a filesystem type like cramfs or squashfs that is specifically meant for this kind of application?

Celada
  • 21,627
  • 4
  • 64
  • 78
  • Indeed it is intended to be read only, i will mount the writable sections via nfs, would changing the fs type require kernel modifications? – fakedrake Feb 21 '13 at 14:13
  • I decided it would be handy to have the filesystem to be writable from within the device so i just let 100K extra space on the output of du. I hope this doesnt break later – fakedrake Feb 21 '13 at 15:07