WHY PFS ?
Posted On Sunday, January 25, 2009 at at 12:26 PM by rajgopalvHere is a detailed Description of the PFS...
Current filesystems have this problem : LIMITED SIZE...
u allocate certain size for a file system, format a file system, done.!
say,
in a 50 hard disk, u have 3 logical partitions
MOVIES | PROJECTS | DOCUMENTS..
20GB........20GB...........10GB
* now consider MOVIES partion is full
* there is 15GB free space in PROJECTS
* still u cant add even a single file in MOVIES !!!
Why not make a file system tat can dynamically expand and shrink...
We'll eliminate the term "VOLUMES, PARTITIONS"... We'll make POOLS!!!
Now, how about,
* MOVIES , PROJECTS, DOCUMENTS share the same 50GB.
* there is no seperate size for each of these.
* data can be added into any of these, till the whole 50GB gets full...
* still MOVIES , PROJECTS, DOCUMENTS can be accesed as different file systems
* they can be mounted, and un mounted seperately..
Now,
* u buy a new harddisk (120 GB)
* u plug-in the harddisk...
* boot ur system...
* "a single command" (pool -add /dev/my_new_harddisk already_existing_pool)
* NO-RE-FORMATTING ur harddisk
* [new space 50 + 120 GB]
* data can be added into any of MOVIES , PROJECTS, DOCUMENTS , till the whole 50GB + 120GB gets full...
it is already implemented in,
ZFS......... Open solaris
ZFS-on-FUSE. LINUX
LVM2 can do this (but not as a readymade file system)
Questions you might want to ponder about the sbd algorithm that you are working on -
1) What is the hardware that you are basing you interface on currently ?
a) ATA
b) SCSI
c) SAS
d) USB
e) Firewire
others ...
2) Most disk low level driver register to the block interface themselves or use a mother helper module to register. So how will your sbd driver fit in?
3) Usually the filesystem that sits on top of such a pool of hardware doesn't have an issue in adding disks or partitions. The issue is when disks get dropped from the pool. How is the file system going to take care of the cleanup especially when the file system handles are held by applications? Inode entries, stale locks, etc.
4)Will resizing be possible on a mounted filesystem or would it require a remount?
I have more questions but I will wait to hear from you first ...
The idea is relevant but would need a lot of design analysis before coding. I guess there isn't fun in just coding and see the code crash in various aspects right :)
1) What is the hardware that you are basing you interface on currently ?
a) ATA
b) SCSI
c) SAS
d) USB
e) Firewire
others ...
We are newbies to kernel programming. So first we'll be using ramdisk. Later on virtual devices. Finally on physical devices.
2) Most disk low level driver register to the block interface themselves or use a mother helper module to register. So how will your sbd driver fit in?
Yes sir. we have problem here... I've posted the same problem HERE in the blog. We are working on this now. May be we should change the drivers little : should export (EXPORT_SYMBOL) the sdb_transfer functions. So file system will call our driver's trasnfer, and this inturn calls the physical disk's transfer (that which is exported.) Are we right ? Is there any other way for our drivers to communicate with the native ones ?
3) Usually the filesystem that sits on top of such a pool of hardware doesn't have an issue in adding disks or partitions. The issue is when disks get dropped from the pool. How is the file system going to take care of the cleanup especially when the file system handles are held by applications? Inode entries, stale locks, etc.
There are lots of issues regarding the file system part sir.
say if a disk is removed,
* How can the inode entries be made okay ?
* In a pool, an inode can have data in more than one disks. what if the disk that is to be removed contains a part of the inode's data?
* For the above qn, if the algo is in such a way that, before romoving : copy all data from the disk tat is to be removed to the disk already present. In this case, what to do if the existing disks have no space atall.?
* adding disks gives more spce
more space means there can be more files can be there in file system
to have more and more files there must be no limit on inode numbers.
How to have infinite number of inodes?
Like this there are a lot of issuses. But we are currently interested in merging/removing devices dynamicaly. We'll look at the filesystem in the next phase of our project.
4)Will resizing be possible on a mounted filesystem or would it require a remount?
LVM achieves resizing without unmounting. We've to find out how it does. But, since this is our academic project, we have limited time. So at first we should achieve atleast resizing by unmounting. Later if possible - resize without unmounting.
We definitely don't want to see our code crashing sir.
Looking forward for your help and guidance.