[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140731171953.GU6754@linux.intel.com>
Date: Thu, 31 Jul 2014 13:19:53 -0400
From: Matthew Wilcox <willy@...ux.intel.com>
To: Boaz Harrosh <openosd@...il.com>
Cc: Matthew Wilcox <matthew.r.wilcox@...el.com>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 04/22] Change direct_access calling convention
On Thu, Jul 31, 2014 at 06:28:37PM +0300, Boaz Harrosh wrote:
> Matthew what is your opinion about this, do we need to push for removal
> of the partition dead code which never worked for brd, or we need to push
> for fixing and implementing new partition support for brd?
Fixing the code gets my vote. brd is useful for testing things ... and
sometimes we need to test things that involve partitions.
> Also another thing I saw is that if we leave the flag
> GENHD_FL_SUPPRESS_PARTITION_INFO
>
> then mount -U UUID stops to work, regardless of partitions or not,
> this is because Kernel will not put us on /proc/patitions.
> I'll submit another patch to remove it.
Yes, we should probably fix that too.
> BTW I hit another funny bug where the partition beginning was not
> 4K aligned apparently fdisk lets you do this if the total size is small
> enough (like 4096 which is default for brd) so I ended up with accessing
> sec zero, the supper-block, failing because of the alignment check at
> direct_access().
That's why I added on the partition start before doing the alignment
check :-)
> Do you know of any API that brd/prd can do to not let fdisk do this?
> I'm looking at it right now I just thought it is worth asking.
I think it's enough to refuse the mount. That feels like a patch to
ext2/4 (or maybe ext2/4 has a way to start the filesystem on a different
block boundary?)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists