From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Subject: Re: [dm-devel] linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac() Date: Thu, 13 Jan 2011 15:43:38 +0100 Message-ID: References: <16069.1294853673@localhost> <4D2E4611.90002@redhat.com> <4D2E6129.8000700@ce.jp.nec.com> <20110113110640.GC30719@htj.dyndns.org> <4D2EE156.1050006@redhat.com> <20110113122701.GG16523@nb.net.home> <20110113131216.GF30719@htj.dyndns.org> <20110113132637.GH16523@nb.net.home> <20110113133722.GG30719@htj.dyndns.org> <4D2F04FF.1070309@redhat.com> <20110113141107.GI30719@htj.dyndns.org> <4D2F0B6A.6010201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Milan Broz , Karel Zak , device-mapper development , "Jun'ichi Nomura" , Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, Alexander Viro , linux-fsdevel@vger.kernel.org To: Tejun Heo Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jan 13, 2011 at 15:30, Tejun Heo wrote: > On Thu, Jan 13, 2011 at 3:25 PM, Milan Broz wrote: >> Maybe, but this was not invented in DM/MD camp:-) >> Probably Kay or Greg can answer why it was done this way? It's not from Greg or Kay. It just appeared some day in the context of = dm. :) And yes, symlinks *look* nice and simple for the outside, but they are not, and have all sorts of problems like non-atomic updates, make it impossible to ever rename a device (as long as they copy the device name), and and and .... we should not add more of this. >> If btrfs internally creates some virtual _block_ device for its pool= , it should >> present it here too with slaves/holders. If not, why it should creat= e any links there? > > Yeah, that's the most bothering part for me. =C2=A0The biggest custom= ers of > bd_claim are filesystems and all these custom symlinkeries don't do > nothing for them. =C2=A0It just doesn't make a whole lot of sense to = me. Btrfs does not use any blockdev as the master for good reason, and it can never map its slaves inside of /sys/block. Simple meta-blockdevs like md/dm just don't fit into modern requirements of a filesystem (directory snapshots, directory subvolumes, complex raids, hassle-free resizing, ...) -- hence btrfs is much more like a network-filesystem mount than a stream of blocks like a disk, and does not fit at all into this model. Kay