From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751677AbdBYEEz convert rfc822-to-8bit (ORCPT ); Fri, 24 Feb 2017 23:04:55 -0500 Received: from mga03.intel.com ([134.134.136.65]:59592 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbdBYEEy (ORCPT ); Fri, 24 Feb 2017 23:04:54 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,202,1484035200"; d="scan'208";a="62009703" Subject: Re: [PATCH 13/14] staging: lustre: llog: limit file size of plain logs Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Oleg Drokin In-Reply-To: <20170224165910.GB9990@kroah.com> Date: Fri, 24 Feb 2017 23:04:40 -0500 Cc: James Simmons , , Andreas Dilger , Alex Zhuravlev , Linux Kernel Mailing List , Lustre Development List Content-Transfer-Encoding: 8BIT Message-Id: <47EC722D-B672-4AD2-BC16-8343E7CA49F1@intel.com> References: <1487454435-4895-1-git-send-email-jsimmons@infradead.org> <1487454435-4895-14-git-send-email-jsimmons@infradead.org> <20170224165910.GB9990@kroah.com> To: Greg Kroah-Hartman X-Mailer: Apple Mail (2.1283) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Feb 24, 2017, at 11:59 AM, Greg Kroah-Hartman wrote: > On Sat, Feb 18, 2017 at 04:47:14PM -0500, James Simmons wrote: >> From: Alex Zhuravlev >> >> on small filesystems plain log can grow dramatically. especially >> given large record sizes produced by DNE and extended chunksize. >> I saw >50% of space consumed by a single llog file which was still >> in use. this leads to test failures (sanityn, etc). >> the patch introduces additional limit on plain llog size, which >> is calculated as /64 (128MB at most) at llog creation >> time. >> >> Signed-off-by: Alex Zhuravlev >> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6838 >> Reviewed-on: https://review.whamcloud.com/18028 >> Reviewed-by: Andreas Dilger >> Reviewed-by: wangdi >> Reviewed-by: Mike Pershin >> Reviewed-by: Oleg Drokin >> Signed-off-by: James Simmons >> --- >> drivers/staging/lustre/lustre/obdclass/llog.c | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/drivers/staging/lustre/lustre/obdclass/llog.c b/drivers/staging/lustre/lustre/obdclass/llog.c >> index 83c5b62..320ff6b 100644 >> --- a/drivers/staging/lustre/lustre/obdclass/llog.c >> +++ b/drivers/staging/lustre/lustre/obdclass/llog.c >> @@ -319,10 +319,26 @@ static int llog_process_thread(void *arg) >> * the case and re-read the current chunk >> * otherwise. >> */ >> + int records; >> + >> if (index > loghandle->lgh_last_idx) { >> rc = 0; >> goto out; >> } >> + /* <2 records means no more records >> + * if the last record we processed was >> + * the final one, then the underlying >> + * object might have been destroyed yet. >> + * we better don't access that.. >> + */ >> + mutex_lock(&loghandle->lgh_hdr_mutex); >> + records = loghandle->lgh_hdr->llh_count; >> + mutex_unlock(&loghandle->lgh_hdr_mutex); >> + if (records <= 1) { >> + rc = 0; >> + goto out; >> + } > > > So you now use the lock, in only one place, when reading a single value? > That makes no sense, it's obviously wrong, or not needed. > > Please fix up these two patches… Ah, this is in fact server-side fix, so all the other users were in the parts not really present in the client. James, we don't really need this patch in the client, I guess.