sparx, India
2009-Aug-09 06:59 UTC
Project idea regarding transparency for distributed systems to be incorporated in the btrfs design
Hi, We are a group of four undergraduate students studying in final year completing our computer engineering course from the University of Pune, India. We would like to do an operating system related project over a period of 6 months. We have studied and understood the design of Btrfs. We came across this paper presented in Fast ''07 on transparent file systems in distributed networks. (TFS) The paper basically suggests some design changes in a regular file system so as to support (and minimize) the efforts of contributory applications for storage resources in a distributed system. This would enable greater resource contribution without affecting local performance ( Storage contribution can increase upto 40% in corporate networks) To support transparent memory allocation to a shared pool efficiently a file sytem should: 1.Allocate most blocks in a given region 2.View storage media as a series of chunks 3.Some replicative power of its own. However the TFS design does not interfere with a file systems own allocation policy. We could not find any article/information which specifically mentions that Btrfs handles memory allocation in distributed systems transparently. We would like to ask your suggestions on the following points: 1. Are we correct in our assumption that Btrfs does not handle transparent allocation as yet or have we missed something? 2. Would the Btrfs community appreciate this contribution to the file system?(i.e. do you think it is worth our investing our time and effort in this and that it contributes positively to btrfs?) Thank-you for your consideration. -Sparx group -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason
2009-Aug-12 18:53 UTC
Re: Project idea regarding transparency for distributed systems to be incorporated in the btrfs design
On Sun, Aug 09, 2009 at 12:29:23PM +0530, sparx, India wrote:> Hi, > We are a group of four undergraduate students studying in final year > completing our computer engineering course from the University of > Pune, India. > > We would like to do an operating system related project over a period > of 6 months. > We have studied and understood the design of Btrfs. > > We came across this paper presented in Fast ''07 on transparent file > systems in distributed networks. (TFS) > The paper basically suggests some design changes in a regular file > system so as to support (and minimize) the efforts of contributory > applications for storage resources in a distributed system. This would > enable greater resource contribution without affecting local > performance ( Storage contribution can increase upto 40% in corporate > networks) > > To support transparent memory allocation to a shared pool efficiently > a file sytem should: > 1.Allocate most blocks in a given region > 2.View storage media as a series of chunks > 3.Some replicative power of its own. > However the TFS design does not interfere with a file systems own > allocation policy. > > We could not find any article/information which specifically mentions > that Btrfs handles memory allocation in distributed systems > transparently. > > We would like to ask your suggestions on the following points: > > 1. Are we correct in our assumption that Btrfs does not handle > transparent allocation as yet or have we missed something?I''m not sure I fully understand the concept of transparent allocation. Could you please describet his in more detail?> 2. Would the Btrfs community appreciate this contribution to the > file system?(i.e. do you think it is worth our investing our time and > effort in this and that it contributes positively to btrfs?)We''re always interested in btrfs contributions ;) Thanks for taking the time to read about the FS and propose this. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html