I don't intend to keep bcache.patch up to date anymore - I need update the wiki... Just do a git merge though, it'd be way easier than dealing with the patch anyways. The docs that refer to the fs UUID are way out of date - the backing device superblock removed the need for that. It should be able to do exactly what you want. On Wed, Nov 9, 2011 at 7:53 PM, Marcus Sorensen <shadowsor@xxxxxxxxx> wrote: > ---------- Forwarded message ---------- > From: Marcus Sorensen <shadowsor@xxxxxxxxx> > Date: Wed, Nov 9, 2011 at 8:49 PM > Subject: bcache.patch > To: kent.overstreet@xxxxxxxxx > > > Was looking for bcache.patch and it's not obvious where I should be > able to find these for various kernel versions. I did suck down the > 3.1 kernel tree in the git repo, but I've put some work into my > existing kernel tree and would like to use that. > > Also, various sources seem to state that it relies on filesystem > UUID, I'm assuming this means that I cannot use it to speed up a block > device that I'm exporting elsewhere (e.g. a logical volume exported as > iscsi or Fibre Channel target, that the client has > partitioned/formatted), because locally I should not be aware of or > using the filesystem, but perhaps I could use it if I were exporting > flat files as volumes to be used elsewhere (cached against the local > fs on which the flat files reside). Is this correct? > > Thanks, > Marcus Sorensen > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
