Re: [HPDD-discuss] Question about OST size
by Dilger, Andreas
On 2015/06/24, 2:58 PM, "David Roman" <David.Roman(a)noveltis.fr> wrote:
>Hello,
>
>
>I saw in the documentation
>https://build.hpdd.intel.com/job/lustre-manual/lastSuccessfulBuild/artifac
>t/lustre_manual.xhtml#understandinglustre.tab.storagerequire
>
>
>==> 1-16 TB per OST, 1-8 OSTs per OSS
>
>
>Is it serious if my OST's size is 40To ?
No, we have tested up to 128TB per OST, though typical maximum size is
about 32-48TB today.
Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel High Performance Data Division
5 years, 11 months
[PATCH] defines modified to match the 80-char rule
by Mario Bambagini
Defines have been written in more than one line to match the 80-character
rule. This error has been fixed 6 times in this file.
The file is fully compliant with respect to the coding rules now.
Signed-off-by: Mario Bambagini <mario.bambagini(a)gmail.com>
---
.../lustre/include/linux/libcfs/libcfs_debug.h | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h b/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
index 8251ac9..aa44311 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
@@ -233,14 +233,20 @@ do { \
#define CNETERR(format, a...) CDEBUG_LIMIT(D_NETERROR, format, ## a)
#define CEMERG(format, ...) CDEBUG_LIMIT(D_EMERG, format, ## __VA_ARGS__)
-#define LCONSOLE(mask, format, ...) CDEBUG(D_CONSOLE | (mask), format, ## __VA_ARGS__)
-#define LCONSOLE_INFO(format, ...) CDEBUG_LIMIT(D_CONSOLE, format, ## __VA_ARGS__)
-#define LCONSOLE_WARN(format, ...) CDEBUG_LIMIT(D_CONSOLE | D_WARNING, format, ## __VA_ARGS__)
-#define LCONSOLE_ERROR_MSG(errnum, format, ...) CDEBUG_LIMIT(D_CONSOLE | D_ERROR, \
- "%x-%x: " format, errnum, LERRCHKSUM(errnum), ## __VA_ARGS__)
-#define LCONSOLE_ERROR(format, ...) LCONSOLE_ERROR_MSG(0x00, format, ## __VA_ARGS__)
+#define LCONSOLE(mask, format, ...) \
+ CDEBUG(D_CONSOLE | (mask), format, ## __VA_ARGS__)
+#define LCONSOLE_INFO(format, ...) \
+ CDEBUG_LIMIT(D_CONSOLE, format, ## __VA_ARGS__)
+#define LCONSOLE_WARN(format, ...) \
+ CDEBUG_LIMIT(D_CONSOLE | D_WARNING, format, ## __VA_ARGS__)
+#define LCONSOLE_ERROR_MSG(errnum, format, ...) \
+ CDEBUG_LIMIT(D_CONSOLE | D_ERROR, "%x-%x: " format, \
+ errnum, LERRCHKSUM(errnum), ## __VA_ARGS__)
+#define LCONSOLE_ERROR(format, ...) \
+ LCONSOLE_ERROR_MSG(0x00, format, ## __VA_ARGS__)
-#define LCONSOLE_EMERG(format, ...) CDEBUG(D_CONSOLE | D_EMERG, format, ## __VA_ARGS__)
+#define LCONSOLE_EMERG(format, ...) \
+ CDEBUG(D_CONSOLE | D_EMERG, format, ## __VA_ARGS__)
int libcfs_debug_msg(struct libcfs_debug_msg_data *msgdata,
const char *format1, ...)
--
2.1.4
5 years, 11 months
lustre: question about lov_request.c
by Julia Lawall
Hello,
The function lov_finish_set in
drivers/staging/lustre/lustre/lov/lov_request.c contains the code:
if (set->set_pga) {
int len = set->set_oabufs * sizeof(*set->set_pga);
OBD_FREE_LARGE(set->set_pga, len);
}
If I change the call to OBD_FREE_LARGE to kvfree, then len is not useful
any more. But actually, at least with grep, I can't find anywhere that
either the set_pga field or the set_oabufs field is set. Am I missing
something, or can the whole if be removed? Can these two fields go too?
thanks,
julia
5 years, 11 months
Re: [HPDD-discuss] [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
by Simmons, James A.
Is this change a hard requirement? Currently the lustre code standard in our development tree is the opposite policy.
-------- Original Message --------
Subject:
[HPDD-discuss] [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
Date:
Sat, 20 Jun 2015 18:58:59 +0200
From:
Julia Lawall <Julia.Lawall(a)lip6.fr><mailto:Julia.Lawall@lip6.fr>
To:
Oleg Drokin <oleg.drokin(a)intel.com><mailto:oleg.drokin@intel.com>
CC:
<devel(a)driverdev.osuosl.org><mailto:devel@driverdev.osuosl.org>, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org><mailto:gregkh@linuxfoundation.org>, <kernel-janitors(a)vger.kernel.org><mailto:kernel-janitors@vger.kernel.org>, <linux-kernel(a)vger.kernel.org><mailto:linux-kernel@vger.kernel.org>, <HPDD-discuss(a)lists.01.org><mailto:HPDD-discuss@lists.01.org>
!x is more normal for kzalloc failure in the kernel.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x;
statement S1, S2;
@@
x = kzalloc(...);
if (
- x == NULL
+ !x
) S1 else S2
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr><mailto:Julia.Lawall@lip6.fr>
---
drivers/staging/lustre/lustre/fid/fid_request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -u -p a/drivers/staging/lustre/lustre/fid/fid_request.c b/drivers/staging/lustre/lustre/fid/fid_request.c
--- a/drivers/staging/lustre/lustre/fid/fid_request.c
+++ b/drivers/staging/lustre/lustre/fid/fid_request.c
@@ -498,11 +498,11 @@ int client_fid_init(struct obd_device *o
int rc;
cli->cl_seq = kzalloc(sizeof(*cli->cl_seq), GFP_NOFS);
- if (cli->cl_seq == NULL)
+ if (!cli->cl_seq)
return -ENOMEM;
prefix = kzalloc(MAX_OBD_NAME + 5, GFP_NOFS);
- if (prefix == NULL) {
+ if (!prefix) {
rc = -ENOMEM;
goto out_free_seq;
}
_______________________________________________
HPDD-discuss mailing list
HPDD-discuss(a)lists.01.org<mailto:HPDD-discuss@lists.01.org>
https://lists.01.org/mailman/listinfo/hpdd-discuss
5 years, 11 months
Re: [HPDD-discuss] Data lost on OST
by David Roman
I do a mistake when i replied. I re-post for all.
-----Message d'origine-----
De : David Roman
Envoyé : mercredi 17 juin 2015 16:07
À : 'Arman Khalatyan'
Objet : RE: [HPDD-discuss] Data lost on OST
I already reboot servers this morning
-----Message d'origine-----
De : David Roman
Envoyé : mercredi 17 juin 2015 16:03
À : 'Arman Khalatyan'
Objet : RE: [HPDD-discuss] Data lost on OST
No, I plan to use 3 OSS servers, each with 1 OST. In a first time I deployed archives-mds (MDT000) and archives-oss3 (OST002). In second time I deployed archives-oss2 (OST001). I never use the third server archives-oss1 (OST000). OST000 doesn't exist.
I do a test just now ...
I copied some data to my lustre volume, about 106 GO.
I have no error with the copy operation. But je problem is the same. I don't have all data. I found data on OST002, but nothing on OST001
-----Message d'origine-----
De : Arman Khalatyan [mailto:arm2arm@gmail.com] Envoyé : mercredi 17 juin 2015 15:53 À : David Roman Objet : Re: [HPDD-discuss] Data lost on OST
what about
OST0000 : Resource temporarily unavailable???
did you recently removed it from MDS?
before lctl lfsck stry to reboot the MDS/OSS After start usually it is starting auto scrub
***********************************************************
Dr. Arman Khalatyan eScience -SuperComputing Leibniz-Institut für Astrophysik Potsdam (AIP) An der Sternwarte 16, 14482 Potsdam, Germany
***********************************************************
On Wed, Jun 17, 2015 at 3:43 PM, David Roman <David.Roman(a)noveltis.fr> wrote:
> Yes if I do
> ls -l /directory/path
> find /directory/path
> lfs find /directory/path
>
> I see my files (240)
>
> If I do
> lfs find -O archives-OST0001 /directory/path ==> I see nothing
> lfs find -O archives-OST0002 /directory/path ==> I see only 4 files, I can read only this files.
>
>
> # lctl dl
> 0 UP osd-ldiskfs archives-MDT0000-osd archives-MDT0000-osd_UUID 10
> 1 UP mgs MGS MGS 51
> 2 UP mgc MGC192.168.1.45@tcp 86f5008e-05e8-6d58-4fa6-64dfebed9dd8 5
> 3 UP mds MDS MDS_uuid 3
> 4 UP lod archives-MDT0000-mdtlov archives-MDT0000-mdtlov_UUID 4
> 5 UP mdt archives-MDT0000 archives-MDT0000_UUID 53
> 6 UP mdd archives-MDD0000 archives-MDD0000_UUID 4
> 7 UP qmt archives-QMT0000 archives-QMT0000_UUID 4
> 8 UP osp archives-OST0002-osc-MDT0000 archives-MDT0000-mdtlov_UUID 5
> 9 UP osp archives-OST0001-osc-MDT0000 archives-MDT0000-mdtlov_UUID 5
> 10 UP lwp archives-MDT0000-lwp-MDT0000
> archives-MDT0000-lwp-MDT0000_UUID 5
> 11 UP lov archives-clilov-ffff880029b0e000
> 3ba711ce-278f-bd95-e4be-9cae34c7a5ab 4
> 12 UP lmv archives-clilmv-ffff880029b0e000
> 3ba711ce-278f-bd95-e4be-9cae34c7a5ab 4
> 13 UP mdc archives-MDT0000-mdc-ffff880029b0e000
> 3ba711ce-278f-bd95-e4be-9cae34c7a5ab 5
> 14 UP osc archives-OST0002-osc-ffff880029b0e000
> 3ba711ce-278f-bd95-e4be-9cae34c7a5ab 5
> 15 UP osc archives-OST0001-osc-ffff880029b0e000
> 3ba711ce-278f-bd95-e4be-9cae34c7a5ab 5
> **********************************************************************
> *****
>
> # lfs df
> UUID 1K-blocks Used Available Use% Mounted on
> archives-MDT0000_UUID 366138224 10685360 330392200 3% /ARCHIVES[MDT:0]
> OST0000 : Resource temporarily unavailable
> archives-OST0001_UUID 42910527264 15650953496 25064315980 38% /ARCHIVES[OST:1]
> archives-OST0002_UUID 42911625592 40387604352 377020420 99% /ARCHIVES[OST:2]
>
> filesystem summary: 85822152856 56038557848 25441336400 69%
> /ARCHIVES
> **********************************************************************
> *****
>
> # cat /proc/fs/lustre/lov/*-MDT0000-mdtlov/target_obd
> 1: archives-OST0001_UUID ACTIVE
> 2: archives-OST0002_UUID ACTIVE
> **********************************************************************
> *****
>
>
>
>
>
>
>
>
> I found some errors about lustre, but I don't understand then.
>
> For exemple :
>
> messages-20150531:May 27 17:41:28 archives-oss2 kernel: LustreError:
> dumping log to /tmp/lustre-log.1432741288.2818 messages-20150531:May
> 27 17:41:28 archives-oss2 kernel: [<ffffffffa080bad1>] ?
> lustre_pack_reply_v2+0x1e1/0x280 [ptlrpc] messages-20150531:May 27
> 17:41:28 archives-oss2 kernel: [<ffffffffa080bc1e>] ?
> lustre_pack_reply_flags+0xae/0x1f0 [ptlrpc] messages-20150531:May 27
> 17:41:28 archives-oss2 kernel: [<ffffffffa080bad1>] ?
> lustre_pack_reply_v2+0x1e1/0x280 [ptlrpc] messages-20150531:May 27
> 17:41:28 archives-oss2 kernel: [<ffffffffa080bc1e>] ?
> lustre_pack_reply_flags+0xae/0x1f0 [ptlrpc] messages-20150531:May 27
> 17:41:28 archives-oss2 kernel: [<ffffffffa080bad1>] ?
> lustre_pack_reply_v2+0x1e1/0x280 [ptlrpc] messages-20150531:May 27
> 17:41:28 archives-oss2 kernel: [<ffffffffa080bc1e>] ?
> lustre_pack_reply_flags+0xae/0x1f0 [ptlrpc]
>
> Can I try to use lctl lfsck ???
>
>
> David
>
>
>
>
> -----Message d'origine-----
> De : Arman Khalatyan [mailto:arm2arm@gmail.com] Envoyé : mercredi 17
> juin 2015 15:16 À : David Roman Cc : hpdd-discuss(a)ml01.01.org Objet :
> Re: [HPDD-discuss] Data lost on OST
>
> Can you see with "ls -l" the file names?
> Do you see any errors in logs? what you can check is connectivity from client to OSTs:
> lctl dl
> lfs df
> or make on mds:
> cat /proc/fs/lustre/lov/*-MDT0000-mdtlov/target_obd
>
> ***********************************************************
>
> Dr. Arman Khalatyan eScience -SuperComputing
> Leibniz-Institut für Astrophysik Potsdam (AIP) An der Sternwarte 16,
> 14482 Potsdam, Germany
>
> ***********************************************************
>
>
> On Wed, Jun 17, 2015 at 11:23 AM, David Roman <David.Roman(a)noveltis.fr> wrote:
>> Hello,
>>
>>
>> I use Lustre 2.6. I have one MDS and 2 OSS servers.
>> When I do a ls command in a specific directory I see my files. But when I want read some them with cat command, the command is blocked.
>>
>> With lfs find -O <device> /my/directory i not see all files !!!
>>
>> Could you help me please ???
>>
>>
>> Tank you
>> _______________________________________________
>> HPDD-discuss mailing list
>> HPDD-discuss(a)lists.01.org
>> https://lists.01.org/mailman/listinfo/hpdd-discuss
5 years, 11 months
Crash of lustre client
by David Roman
Hi,
On a other Lustre files system, I have a problem with 2 clients.
They crash and I see nothing in log file. Just the end of error messages on the console. See the attached file.
Someone already saw this problem ?
David
5 years, 11 months
Re: [HPDD-discuss] [PATCH 09/12] staging: lustre: obdclass: Use !x to check for kzalloc failure
by Julia Lawall
> > @@ -885,7 +885,7 @@ static int lmd_parse_mgssec(struct lustr
> > length = tail - ptr;
> >
> > lmd->lmd_mgssec = kzalloc(length + 1, GFP_NOFS);
> > - if (lmd->lmd_mgssec == NULL)
> > + if (!lmd->lmd_mgssec)
> > return -ENOMEM;
> >
> > memcpy(lmd->lmd_mgssec, ptr, length);
> looks like memdup()
kmemdup has the same length for both calls. There is kstrndup, but it
recalculates the length, which looks unnecessary here.
julia
5 years, 12 months
