On Thu, 2014-07-31 at 14:30 -0600, Ross Zwisler wrote:

On Thu, 2014-07-31 at 21:04 +0300, Boaz Harrosh wrote:

quoted

On 07/31/2014 08:19 PM, Matthew Wilcox wrote:

quoted

On Thu, Jul 31, 2014 at 06:28:37PM +0300, Boaz Harrosh wrote:

quoted

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.

OK I'm on it, its what I'm doing today.

rrr I manged to completely trash my vm by doing 'make install' of
util-linux and after reboot it never recovered, I remember that
mount complained about a now missing library and I forgot and rebooted,
that was the end of that. Anyway I installed a new fc20 system wanted
that for a long time over my old fc18

Ah, I'm already working on this as well.  :)  If you want you can wait for my
patches to BRD & test - they should be out this week.

I'm planning on adding get_geo() and doing dynamic minors as is done in NVMe.

Ugh, it turns out that if you remove the "*part = 0" bit from brd_probe(),
attempts to create new BRD devices using mknod hit a deadlock.  Removal of
that code, ie:

@@ -550,7 +549,6 @@ static struct kobject *brd_probe(dev_t dev, int *part, void *data)
        kobj = brd ? get_disk(brd->brd_disk) : NULL;
        mutex_unlock(&brd_devices_mutex);

-       *part = 0;
        return kobj;
 }

is necessary if we want to do any sort of partitioning.

This isn't a use case for PRD, so I'll move over to that and try to add
dynamic minors there instead.  If we really do want partitions to work in BRD,
though, eventually we'll have to debug the deadlock.

- Ross

�{.n�+���zwZ��,j���n�˛���m�b��f�)���w+h����&�K�rJ+�Z+��ފw�r��L2Ǟ��i��0�X�����?��zf���ky���[hv�������zf��K�rJ+��