[DRBD-user] mkfs hangs

Todd Denniston Todd.Denniston at ssa.crane.navy.mil
Fri Jan 20 20:26:04 CET 2006

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


Chip Burke wrote:
> Good call. It is FC4 2.6.14_1656 . Do I need to go back just one revision?
> Or is there a specific kernel where this problem popped up?
> 

Lars, Philipp,
With this thread and the "Commands freeze when accessing drbd device..." 
thread, it looks like something has been botched with the current Fedora Core 
4 (FC4) 2.6 kernel. Can you give us some hints on how to figure out what is 
causing the fault, as it is not kind enough to throw an OOPS pointing at the 
source[2].

Looking at a diff of the two trees, out of the 42 files with changes, the 
files I would put the highest chance of causing the problem to be:
drivers/block/ll_rw_blk.c
# generic_make_request(struct bio *bio) was renamed to
# __generic_make_request(struct bio *bio), and the new
# generic_make_request(struct bio *bio) was created with
# a loop in it calling __generic_make_request.
# The comment at the top of the new generic_make_request is:
+/*
+ * We only want one ->make_request_fn to be active at a time,
+ * else stack usage with stacked devices could be a problem.
+ * So use current->bio_{list,tail} to keep a list of requests
+ * submited by a make_request_fn function.
+ * current->bio_tail is also used as a flag to say if
+ * generic_make_request is currently active in this task or not.
+ * If it is NULL, then no make_request is active.  If it is non-NULL,
+ * then a make_request is active, and new requests should be added
+ * at the tail
+ */
#so it looks like they modified the way "stacked devices" are handled...
#HMMM... DRBD on LVM on IDE/SCSI ...
#still I don't have a plan to prove the fault.
#The above change comes from a patch Neil Brown sent to 
linux-kernel at vger.kernel.org
"Mon, 7 Nov 2005 11:16:48"
  Subject: do_mount: reduce stack consumption
Signed-off-by: Neil Brown <neilb at cse.unsw.edu.au>
Signed-off-by: Neil Brown <neilb at suse.de>


#other possibly interesting files.
drivers/acpi/utilities/utmisc.c
kernel/sysctl.c
mm/rmap.c
#if they are using scsi (none of the reporters has
#indicated what the physical hardware they are using was)
#the following may be interesting
drivers/scsi/dpt_i2o.c
drivers/scsi/scsi_lib.c
drivers/scsi/sd.c

I think we (those of us using FC4) will need to file a bug with Fedora[1] so 
this does not become a reoccurring fault keeping us stuck at an old kernel.



[1] Well at least for now I will blame Fedora :)
It is not impossible for us to find something DRBD is doing, is being done in 
an interesting way. :)

[2] Or as I have not yet tried the new kernel & drbd, I assume the folks are 
not missing the OOPS because their server being in runlevel 5 instead of 3.


> Thanks so much
> 
> ________________________________________
> Chip Burke
> 
> 
> -----Original Message-----
> From: Anquijix Schiptara [mailto:anquijix at hotmail.com] 
> Sent: Friday, January 20, 2006 10:34 AM
> To: cburke at innova-partners.com
> Subject: RE: [DRBD-user] mkfs hangs
> 
> If you run FC4 with newest kernel, install an older version, reinstall drbd 
> module, and all good... There is already a similar thread according to the 
> newest FC4-Kernel.
> 
> 
>>From: "Chip Burke" <cburke at innova-partners.com>
>>Reply-To: cburke at innova-partners.com
>>To: <drbd-user at linbit.com>
>>Subject: [DRBD-user] mkfs hangs
>>Date: Fri, 20 Jan 2006 10:13:44 -0500
>>
>>I am running 0.7.15 and I cannot seem to format a drive. When I go to run
>>'mkfs -j /dev/drbd0', mfks hangs while writing the inode tables at the same
>>place every time. If I stop drbd and format the underlying device, it works
>>fine, but the drbd device is not a happy camper. Any ideas as to what the
>>issue may be? /dev/drbd0 is set to primary and syncs just fine with it's
>>slave, so everything seems okay. but the drive isn't much good with out a
>>files system.



More information about the drbd-user mailing list