[DRBD-user] Shrinking Filesystem

CA Lists lists at creativeanvil.com
Fri Jun 22 19:11:04 CEST 2007

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

> On Fri, Jun 22, 2007 at 11:32:51AM -0500, CA Lists wrote:
>> There was nothing on the drives at all. In a chicken-before-egg type of
>> situation, since I don't have /dev/sdb mounted anywhere on the iSCSI
>> targets, I thought I would need to get OCFS2 up and running on one of the
>> nodes and format the drive to be able to do anything with it. Then, I found
>> out ocfs2 provides no way to shrink a filesystem.
> the correct way to set up a fresh file system on drbd is to
>  * setup drbd, 
>  * then do mkfs /dev/drbdX,
> and all will be fine.
>> So, /proc/partitions shows a number that is 29492 smaller, which means bad
>> things, right? In other words, I need to probably re-make the ocfs2 file
>> system to be smaller, correct?
> if you just make it on top of drbd, all is fine.

OK, so on the target machine, I just remade the file system with mkfs.ocfs2
and now my number from /proc/partitions is larger by 12 blocks, which means
my data will now be safe, right?

> what are you trying to do there?
> I mean, if I would export some blockdevice via iSCSI,
> I'd not mount it locally, even with a cluster fs.
> it just does not feel right, and probably asks for trouble
> like resoiurce starvation deadlocks.

That's what got me confused to begin with. I wanted to avoid mounting it
locally. My issue was how to format a drive for ocfs2 without one of the
nodes being able to see it. I was being stupid though - just had to export
the /dev/drbd0 device over iSCSI, then format the device.
> (well, actually, all block-io via linux network stack asks for trouble
> of this kind, though it has been getting better.)

More information about the drbd-user mailing list