From patchwork Thu Feb 26 08:41:46 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boaz Harrosh X-Patchwork-Id: 5889931 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 292239F373 for ; Thu, 26 Feb 2015 08:41:53 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6730C20374 for ; Thu, 26 Feb 2015 08:41:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B7D820382 for ; Thu, 26 Feb 2015 08:41:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751340AbbBZIlu (ORCPT ); Thu, 26 Feb 2015 03:41:50 -0500 Received: from mail-we0-f178.google.com ([74.125.82.178]:33559 "EHLO mail-we0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751577AbbBZIlt (ORCPT ); Thu, 26 Feb 2015 03:41:49 -0500 Received: by wevk48 with SMTP id k48so8584138wev.0 for ; Thu, 26 Feb 2015 00:41:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=X/ZppnGbJ5Gvfmxe8++vinCGGM2GYy5rz/AvZ3nr970=; b=kA2uqR243Q6gQ776FwidbXW1A44HE8HQV55PbL9u4I8fBiJPKlXL/P4DdSdhprOdZZ POzs3hyQWANfYvFEAvkwfgRlJJ3yzpnAR+PUZ/cPZgYANF5ha29lg/Jdqb8sEM0qYnkQ tqQAqymxK5nhJP5xDbprGqE7lHOofh4CAusZLKICdfEWyPEqKAKc/8+WsjJOxoiLW9Gk fGYBYUOXPh0NHTiKalMH57LmzHR1VW1u3Zxv77SfHS2/PxnhdPslVOpKGWFTB0N3gYSv miPpko67XszTFTxsf45OUtG5Tisgti70Lc1SRwDT7URA/uHnkmtHMLypyxYszo10Eb2p hPTg== X-Gm-Message-State: ALoCoQlWe0BfjTP0ptQ5uZ9siSk59fL9+sCxDT+HREThcSnGiIELwEixv3lVUK27JkJRFYSvXO/1 X-Received: by 10.194.192.4 with SMTP id hc4mr14381534wjc.59.1424940108072; Thu, 26 Feb 2015 00:41:48 -0800 (PST) Received: from [10.0.0.5] ([207.232.55.62]) by mx.google.com with ESMTPSA id cj12sm283135wjb.35.2015.02.26.00.41.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 00:41:47 -0800 (PST) Message-ID: <54EEDC4A.8090000@plexistor.com> Date: Thu, 26 Feb 2015 10:41:46 +0200 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jens Axboe , Dave Chinner CC: Brian Foster , fstests@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH] brd: Only request 4K sectors if DAX is enabled References: <1424818479-10083-1-git-send-email-david@fromorbit.com> <1424818479-10083-2-git-send-email-david@fromorbit.com> <20150225161151.GC28053@bfoster.bfoster> <20150225223248.GH4251@dastard> <54EED5F6.2030804@plexistor.com> In-Reply-To: <54EED5F6.2030804@plexistor.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP People systems have been using ramdisk with smaller-than-page-size blocks in their mkfs. The 4K sectors is only important if we will be using brd with a DAX filesystem. So only enable 4K sectors if DAX is configured Signed-off-by: Boaz Harrosh --- drivers/block/brd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/block/brd.c b/drivers/block/brd.c index 6e0775b..e875f12 100644 --- a/drivers/block/brd.c +++ b/drivers/block/brd.c @@ -495,6 +495,7 @@ static struct brd_device *brd_alloc(int i) blk_queue_max_hw_sectors(brd->brd_queue, 1024); blk_queue_bounce_limit(brd->brd_queue, BLK_BOUNCE_ANY); +#ifdef CONFIG_BLK_DEV_RAM_DAX /* This is so fdisk will align partitions on 4k, because of * direct_access API needing 4k alignment, returning a PFN * (This is only a problem on very small devices <= 4M, @@ -502,6 +503,7 @@ static struct brd_device *brd_alloc(int i) * is harmless) */ blk_queue_physical_block_size(brd->brd_queue, PAGE_SIZE); +#endif brd->brd_queue->limits.discard_granularity = PAGE_SIZE; brd->brd_queue->limits.max_discard_sectors = UINT_MAX;