OS: Centos 5.3, x86_64
Kernel: 2.6.18-128.1.6
[root at attractor ~]# cat /proc/fs/lustre/version
lustre: 1.9.210
..
Looking for mkfs.ldiskfs during mkfs.lustre?
Did a find on previous working lustre-1.9 working and didn''t find one.
Ps advice.
[root at attractor ~]# mkfs.lustre --fsname=jwan0 --mdt --mgs /dev/hdc1
Permanent disk data:
Target: jwan0-MDTffff
Index: unassigned
Lustre FS: jwan0
Mount type: ldiskfs
Flags: 0x75
(MDT MGS needs_index first_time update )
Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr
Parameters:
checking for existing Lustre data: not found
device size = 19085MB
2 6 18
formatting backing filesystem ldiskfs on /dev/hdc1
target name jwan0-MDTffff
4k blocks 0
options -J size=400 -i 4096 -I 512 -q -O
dir_index,uninit_groups -F
mkfs_cmd = mkfs.ldiskfs -j -b 4096 -L jwan0-MDTffff -J size=400 -i 4096
-I 512 -q -O dir_index,uninit_groups -F /dev/hdc1
sh: mkfs.ldiskfs: command not found
mkfs.lustre FATAL: Unable to build fs /dev/hdc1 (32512)
mkfs.lustre FATAL: mkfs failed 32512
Thanks,
josephin
On Jul 01, 2009 13:03 -0400, Josephine Palencia wrote:> [root at attractor ~]# cat /proc/fs/lustre/version > lustre: 1.9.210 > > Looking for mkfs.ldiskfs during mkfs.lustre? > Did a find on previous working lustre-1.9 working and didn''t find one. > Ps advice.Well, mkfs.ldiskfs doesn''t exist, it should just be using mkfs.ext3 to create the backing filesystem. Please file a bug against the 1.9.210 release (if it exists), or HEAD.> [root at attractor ~]# mkfs.lustre --fsname=jwan0 --mdt --mgs /dev/hdc1 > > Permanent disk data: > Target: jwan0-MDTffff > Index: unassigned > Lustre FS: jwan0 > Mount type: ldiskfs > Flags: 0x75 > (MDT MGS needs_index first_time update ) > Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr > Parameters: > > checking for existing Lustre data: not found > device size = 19085MB > 2 6 18 > formatting backing filesystem ldiskfs on /dev/hdc1 > target name jwan0-MDTffff > 4k blocks 0 > options -J size=400 -i 4096 -I 512 -q -O > dir_index,uninit_groups -F > mkfs_cmd = mkfs.ldiskfs -j -b 4096 -L jwan0-MDTffff -J size=400 -i 4096 > -I 512 -q -O dir_index,uninit_groups -F /dev/hdc1 > sh: mkfs.ldiskfs: command not found > > mkfs.lustre FATAL: Unable to build fs /dev/hdc1 (32512) > > mkfs.lustre FATAL: mkfs failed 32512Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
On Jul 1, 2009, at 10:03 , Josephine Palencia wrote:> > OS: Centos 5.3, x86_64 > Kernel: 2.6.18-128.1.6 > > [root at attractor ~]# cat /proc/fs/lustre/version > lustre: 1.9.210 > .. > > Looking for mkfs.ldiskfs during mkfs.lustre? > Did a find on previous working lustre-1.9 working and didn''t find one. > Ps advice. >What configure options did you use when you built lustre? I think "-- with-ldiskfsprogs" will configure lustre to use these names, however the standard version the e2fs utils doesn''t use this naming scheme. This would be used, for instance, if you needed to have both the original and ldiskfs version of e2fsutils installed at the same time. robert> [root at attractor ~]# mkfs.lustre --fsname=jwan0 --mdt --mgs /dev/hdc1 > > Permanent disk data: > Target: jwan0-MDTffff > Index: unassigned > Lustre FS: jwan0 > Mount type: ldiskfs > Flags: 0x75 > (MDT MGS needs_index first_time update ) > Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr > Parameters: > > checking for existing Lustre data: not found > device size = 19085MB > 2 6 18 > formatting backing filesystem ldiskfs on /dev/hdc1 > target name jwan0-MDTffff > 4k blocks 0 > options -J size=400 -i 4096 -I 512 -q -O > dir_index,uninit_groups -F > mkfs_cmd = mkfs.ldiskfs -j -b 4096 -L jwan0-MDTffff -J size=400 -i > 4096 > -I 512 -q -O dir_index,uninit_groups -F /dev/hdc1 > sh: mkfs.ldiskfs: command not found> > mkfs.lustre FATAL: Unable to build fs /dev/hdc1 (32512) > > mkfs.lustre FATAL: mkfs failed 32512 > > > Thanks, > josephin > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss
On Wed, 2009-07-01 at 16:50 -0700, Robert Read wrote:> > What configure options did you use when you built lustre? I think "-- > with-ldiskfsprogs" will configure lustre to use these names, however > the standard version the e2fs utils doesn''t use this naming scheme.If the --with-ldiskfsprogs was indeed used, perhaps/probably, configure should check that ldiskfsprogs was installed on the build system. Additionally, the Requires: tags in the resulting RPM should probably be changed to ldiskfsprogs from e2fsprogs, if that is not already being done. Perhaps Josephine could file a bug to those effects. Given that having the ldiskfsprogs flavour of the utilities installed is strictly a run-time requirement, perhaps the above configure enhancement not be so strict, but certainly the latter, the RPM requirement, should be. If Josephine had installed resulting RPMs, that would have been her signal that things were not quite aligning. If configure is not so strict, it could at least warn about the missing utilities. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090702/fb8fc7f8/attachment.bin
On Thu, Jul 02, 2009 at 10:44:39AM -0400, Brian J. Murrell wrote:> On Wed, 2009-07-01 at 16:50 -0700, Robert Read wrote: > > > > What configure options did you use when you built lustre? I think "-- > > with-ldiskfsprogs" will configure lustre to use these names, however > > the standard version the e2fs utils doesn''t use this naming scheme. > > If the --with-ldiskfsprogs was indeed used, perhaps/probably, configure > should check that ldiskfsprogs was installed on the build system. > Additionally, the Requires: tags in the resulting RPM should probably be > changed to ldiskfsprogs from e2fsprogs, if that is not already being > done. > > Perhaps Josephine could file a bug to those effects. > > Given that having the ldiskfsprogs flavour of the utilities installed is > strictly a run-time requirement, perhaps the above configure enhancement > not be so strict, but certainly the latter, the RPM requirement, should > be. If Josephine had installed resulting RPMs, that would have been her > signal that things were not quite aligning. If configure is not so > strict, it could at least warn about the missing utilities.I agree that the spec file must have a Requires: ldiskfsprogs (ours does). Adding a build-time requirement (and presumably BuildRequires:) just adds unnecessary work at build time for modern build systems such as mock. Please don''t do that. Jim p.s. See bug 17963 for background on --with-ldiskfsprogs.
On Thu, 2009-07-02 at 09:29 -0700, Jim Garlick wrote:> > Adding a build-time requirement (and presumably BuildRequires:)No, not at all a BuildRequires: as it''s not really needed for building. The only reason I''d propose a configure check is to prevent the "tar xzvf lustre-...tar.gz; configure; make; make install; mkfs ..." scenario from tripping over the same problem. Maybe the reality is that we cannot do enough to protect people who want to use the above MO for building their Lustre systems. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090702/e38f925c/attachment-0001.bin
On Thu, Jul 02, 2009 at 12:34:07PM -0400, Brian J. Murrell wrote:> On Thu, 2009-07-02 at 09:29 -0700, Jim Garlick wrote: > > > > Adding a build-time requirement (and presumably BuildRequires:) > > No, not at all a BuildRequires: as it''s not really needed for building. > > The only reason I''d propose a configure check is to prevent the "tar > xzvf lustre-...tar.gz; configure; make; make install; mkfs ..." scenario > from tripping over the same problem.We''ve been using our own spec file with Lustre for some time so maybe I am not aware of how it is currently done, but normally a spec file would do a configure; make in its %build section. If that is the case and configure --with-ldiskfsprogs fails without ldiskfsprogs installed, then you would need a BuildRequires: ldiskfsprogs because people building in a mock chroot will only have the OS base packages plus the package''s BuildRequires: packages installed in the chroot. Jim
On Thu, 2009-07-02 at 09:51 -0700, Jim Garlick wrote:> > We''ve been using our own spec file with Lustre for some time so maybe > I am not aware of how it is currently done, but normally a spec file > would do a configure; make in its %build section.Yes. Same for our spec file.> If that is the case and configure --with-ldiskfsprogs fails without > ldiskfsprogs installed, then you would need a BuildRequires: ldiskfsprogs > because people building in a mock chroot will only have the OS base packages > plus the package''s BuildRequires: packages installed in the chroot.Indeed, you are correct. All of which has given me great pause to making it a strict build time requirement. Certainly not without an "i know what i am doing" kind of option to override it. All of this is just thinking aloud anyway and it''s getting exactly the kind of feedback I''d want before doing anything of the sort. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090702/69a9bf18/attachment.bin
On Jul 02, 2009 10:44 -0400, Brian J. Murrell wrote:> If the --with-ldiskfsprogs was indeed used, perhaps/probably, configure > should check that ldiskfsprogs was installed on the build system. > Additionally, the Requires: tags in the resulting RPM should probably be > changed to ldiskfsprogs from e2fsprogs, if that is not already being > done. > > Perhaps Josephine could file a bug to those effects. > > Given that having the ldiskfsprogs flavour of the utilities installed is > strictly a run-time requirement, perhaps the above configure enhancement > not be so strict, but certainly the latter, the RPM requirement, should > be. If Josephine had installed resulting RPMs, that would have been her > signal that things were not quite aligning. If configure is not so > strict, it could at least warn about the missing utilities.I wouldn''t support a BuildRequires, since I''ve had enough trouble with those in the past that I don''t like them at all. However, we''ve been shipping e2fsprogs with a "Provides: ldiskfsprogs" for long enough (at least 1.40.5.sun1, I haven''t checked earlier) that we could consider also add a "Requires: ldiskfsprogs" to our lustre .spec so that we are sure that a Lustre-aware e2fsprogs is available. The one problem is that e2fsprogs/ldiskfsprogs is NOT required on the client, and I wouldn''t want to force this on every client. I don''t think we have separate server RPMs, so I don''t know if there is an easy answer. Note also that the Lustre e2fsprogs doesn''t provide a "mkfs.ldiskfs", "fsck.ldiskfs", or any similar tool. That is only in LLNL''s RPM, and the "--with-ldiskfsprogs" option shouldn''t really be used by anyone else. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.
On Fri, 2009-07-03 at 00:00 +0200, Andreas Dilger wrote:> > I wouldn''t support a BuildRequires, since I''ve had enough trouble with > those in the past that I don''t like them at all.Well, if they are needed and used properly, they are good as they prevent you from going down an rpmbuild path only to have it bail 90% of the way done because something needed is not installed. Indeed however they can be troublesome with the kind of spec files we still have around -- the single spec trying to satisfy multiple distros; those are just generally trouble. The kinds of trouble they cause is exactly what has led to us abandoning our own kernel spec and using each vendor''s own kernel spec now. But I digress. In any case, I think Jim and I have discussed in this thread elsewhere that a BuildRequires on an ldiskfsprogs is not really the right tool here anyway.> However, we''ve been shipping e2fsprogs with a "Provides: ldiskfsprogs" > for long enough (at least 1.40.5.sun1, I haven''t checked earlier) that > we could consider also add a "Requires: ldiskfsprogs" to our lustre .specI don''t think that would solve the original problem though, as my proposal for (conditionally, if the corresponding configure flag was used) adding Requires: ldiskfsprogs to lustre.spec would be meant to really require an ldiskfs branded e2fsprogs (i.e. with executables named s/ext3/ldiskfs/).> so that we are sure that a Lustre-aware e2fsprogs is available.I certainly wouldn''t disagree with doing this, but I think that''s a different problem and solution pair. Certainly, having both e2fsprogs and ldiskfsprogs RPMs Provide: lustre-e2fsprogs and having the lustre packages Require: lustre-e2fsprogs would be good, but orthogonal to OP''s problem.> The one > problem is that e2fsprogs/ldiskfsprogs is NOT required on the client, > and I wouldn''t want to force this on every client.Sure. It should only be required by servers. But given that we lack a lustre-servers separate package, it gets tricky considering the servers package could be installed on what''s really a client. This all begs the lustre packaging (i.e. the rpm split up) to be overhauled.> I don''t think we > have separate server RPMs, so I don''t know if there is an easy answer.Heh. What he said. :-)> Note also that the Lustre e2fsprogs doesn''t provide a "mkfs.ldiskfs", > "fsck.ldiskfs", or any similar tool. That is only in LLNL''s RPM, and > the "--with-ldiskfsprogs" option shouldn''t really be used by anyone > else.Well, it is there. I don''t know about others shouldn''t be using it and whatnot, but if the option is there, it should be complete (well as complete as it could reasonably be), imho. Given our current rpms though, it probably already is. Just fodder for the future. :-) b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090702/cea587b9/attachment-0001.bin