<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = "urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word" xmlns:m = "http://schemas.microsoft.com/office/2004/12/omml"><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.3429" name=GENERATOR> <STYLE>@font-face { font-family: Cambria Math; } @font-face { font-family: Calibri; } @page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; } P.MsoNormal { FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Calibri","sans-serif" } LI.MsoNormal { FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Calibri","sans-serif" } DIV.MsoNormal { FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Calibri","sans-serif" } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.EmailStyle17 { COLOR: windowtext; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-compose } .MsoChpDefault { mso-style-type: export-only } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=EL vLink=purple link=blue> <DIV dir=ltr align=left>Don't use GFS2 on CentOS 5.2. It simply isn't ready.</DIV> <DIV dir=ltr align=left> </DIV> <DIV dir=ltr align=left>You'll want to setup either GFS1 instead, or wait for CentOS 5.3.</DIV> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left> <HR tabIndex=-1> From: linux-cluster-bounces@redhat.com [mailto:linux-cluster-bounces@redhat.com] On Behalf Of Theophanis Kontogiannis Sent: Sunday, March 22, 2009 5:11 PM To: 'linux clustering' Subject: [Linux-cluster] Can not create a GFS2 filesystem with block size of512 </DIV> <DIV></DIV> <DIV class=Section1> Hello all,<o:p></o:p> <o:p> </o:p> I have:<o:p></o:p> <o:p> </o:p> Two nodes cluster with exactly the same hardware (4GB RAM, AMD X2, 1TB SATAII disk, 320GB PATA disk)<o:p></o:p> Centos 5.2<o:p></o:p> 2.6.18-92.1.22.el5.centos.plus<o:p></o:p> gfs2-utils-0.1.44-1.el5_2.1<o:p></o:p> kmod-gfs-0.1.23-5.el5_2.4<o:p></o:p> <o:p> </o:p> I try to create GFS2 on 1TB LV (on the SATA disk) with ‘mkfs.gfs2 -b 512 -t tweety:gfs2-01 -p lock_dlm -j 10 /dev/mapper/vg1-data1’<o:p></o:p> <o:p> </o:p> I want to use 512 block size. Since the command looked that it last forever, I used –D option to look on what is going on. This visualized the fact that nothing happens after initial effort to create Journal 3.<o:p></o:p> <o:p> </o:p> Because I got those freezes during mkfs.gfs2, I used ‘vmstat –p /dev/sda1’ on a second terminal to observe disk activity. This confirmed that there is no disk activity after the initial effort to create Journal 3.<o:p></o:p> <o:p> </o:p> I thought that it might be a problem of how I created the LV so I erase all VG, LV and PV and try to create the file system on the physical device.<o:p></o:p> <o:p> </o:p> The creation of GFS2 on the physical partition also freezes on Journal 3.<o:p></o:p> <o:p> </o:p> This is the extract of the output of ‘mkfs.gfs2 -D -b 512 -t tweety:gfs2-01 -p lock_dlm -j 10 /dev/sda1’ (which is same to the output I get when using the LV instead of the physical partition):<o:p></o:p> <o:p> </o:p> ………………………<o:p></o:p> ri_addr: 1951423390 ri_length: 269 ri_data0: 1951423659 ri_data: 523884 ri_bitbytes: 130971<o:p></o:p> ri_addr: 1951947543 ri_length: 269 ri_data0: 1951947812 ri_data: 523884 ri_bitbytes: 130971<o:p></o:p> ri_addr: 1952471696 ri_length: 269 ri_data0: 1952471965 ri_data: 523884 ri_bitbytes: 130971<o:p></o:p> ri_addr: 1952995849 ri_length: 269 ri_data0: 1952996118 ri_data: 523884 ri_bitbytes: 130971<o:p></o:p> Root directory:<o:p></o:p> mh_magic: 0x01161970 mh_type: 4 mh_format: 400 no_formal_ino: 1 no_addr: 399 di_mode: 040755 di_uid: 0 di_gid: 0 di_nlink: 2 di_size: 280 di_blocks: 1 di_atime: 1237752111 di_mtime: 1237752111 di_ctime: 1237752111 di_major: 0 di_minor: 0 di_goal_meta: 399 di_goal_data: 399 di_flags: 0x00000001 di_payload_format: 1200 di_height: 0 di_depth: 0 di_entries: 2 di_eattr: 0<o:p></o:p> Master dir:<o:p></o:p> mh_magic: 0x01161970 mh_type: 4 mh_format: 400 no_formal_ino: 2 no_addr: 400 di_mode: 040755 di_uid: 0 di_gid: 0 di_nlink: 2 di_size: 280 di_blocks: 1 di_atime: 1237752111 di_mtime: 1237752111 di_ctime: 1237752111 di_major: 0 di_minor: 0 di_goal_meta: 400 di_goal_data: 400 di_flags: 0x00000201 di_payload_format: 1200 di_height: 0 di_depth: 0 di_entries: 2 di_eattr: 0<o:p></o:p> Super Block:<o:p></o:p> mh_magic: 0x01161970 mh_type: 1 mh_format: 100 sb_fs_format: 1801 sb_multihost_format: 1900 sb_bsize: 512 sb_bsize_shift: 9 no_formal_ino: 2 no_addr: 400 no_formal_ino: 1 no_addr: 399 sb_lockproto: lock_dlm sb_locktable: tweety:gfs2-01<o:p></o:p> Journal 0:<o:p></o:p> mh_magic: 0x01161970 mh_type: 4 mh_format: 400 no_formal_ino: 4 no_addr: 402 di_mode: 0100600 di_uid: 0 di_gid: 0 di_nlink: 1 di_size: 134217728 di_blocks: 266516 di_atime: 1237752111 di_mtime: 1237752111 di_ctime: 1237752111 di_major: 0 di_minor: 0 di_goal_meta: 4773 di_goal_data: 266917 di_flags: 0x00000200 di_payload_format: 0 di_height: 4 di_depth: 0 di_entries: 0 di_eattr: 0<o:p></o:p> Journal 1:<o:p></o:p> mh_magic: 0x01161970 mh_type: 4 mh_format: 400 no_formal_ino: 5 no_addr: 266918 di_mode: 0100600 di_uid: 0 di_gid: 0 di_nlink: 1 di_size: 134217728 di_blocks: 266516 di_atime: 1237752111 di_mtime: 1237752111 di_ctime: 1237752111 di_major: 0 di_minor: 0 di_goal_meta: 271289 di_goal_data: 533703 di_flags: 0x00000200 di_payload_format: 0 di_height: 4 di_depth: 0 di_entries: 0 di_eattr: 0<o:p></o:p> Journal 2:<o:p></o:p> mh_magic: 0x01161970 mh_type: 4 mh_format: 400 no_formal_ino: 6 no_addr: 533704 di_mode: 0100600 di_uid: 0 di_gid: 0 di_nlink: 1 di_size: 134217728 di_blocks: 266516 di_atime: 1237752111 di_mtime: 1237752111 di_ctime: 1237752111 di_major: 0 di_minor: 0 di_goal_meta: 538075 di_goal_data: 800219 di_flags: 0x00000200 di_payload_format: 0 di_height: 4 di_depth: 0 di_entries: 0 di_eattr: 0<o:p></o:p> Journal 3:<o:p></o:p> <o:p> </o:p> After that I have no disk activity and no logging.<o:p></o:p> <o:p> </o:p> There is no message from the kernel.<o:p></o:p> <o:p> </o:p> Anyone knows the reason for that behavior, and what is the minimum block size I can use (I have tested 1024 and it works fine)?<o:p></o:p> <o:p> </o:p> Thank you all for your time.<o:p></o:p> <o:p> </o:p> Theophanis Kontogiannis<o:p></o:p> <o:p> </o:p></DIV></BLOCKQUOTE></BODY></HTML>