* Re: Fwd: XFS
2014-07-23 18:23 ` Fwd: XFS Somdeep Dey
@ 2014-07-25 2:16 ` Dave Chinner
0 siblings, 0 replies; 2+ messages in thread
From: Dave Chinner @ 2014-07-25 2:16 UTC (permalink / raw)
To: Somdeep Dey; +Cc: xfs
On Wed, Jul 23, 2014 at 11:53:26PM +0530, Somdeep Dey wrote:
> Hello,
> We are a group of students that are currently pursuing our undergraduate
> degrees in Computer Science from Pune Institute of Computer Technology
> (PICT), Maharashtra, India. We will be graduating in June 2015 and are
> currently in our final year. For our final year B.E project we have
> selected the domain as Systems and would be very interested in working in
> the field of journalling file systems, which is where we stumbled upon XFS.
> Over the past few weeks we have been extensively studying the various
> features and working principles which has allowed this filesystem to
> prosper. It will be a great learning opportunity for us to work with XFS
> and in turn work with you. As per given on the *http://xfs.org/
> <http://xfs.org/>* website for contributions, we would appreciate if you
> could steer us towards the direction of choosing the right topic and
> working towards culminating a project in the same, which would be helpful
> for the community.
My first concern is this: Do you have permission from PICT to
publish your work under the GPL or LGPL (depending on whether it is
kernel or userspace code you write)? If not, then we can't use the
work you do and so you can guess how much interest we'd have in
that case...
> 4) Development time ( 6 to 7 months from August to February )
So nothing too complex then...
> We would love to hear from about any ideas that you see fit for us to
> pursue and which are feasible in the specified time frame. Hoping to hear
> from you soon, and thanking you in anticipation.
Well, given the timeframe and your capabilities, I'd suggest that
developing new core infrastructure features might be a bit of a
stretch. However, I think that taking one of the userspace utilities
and enhancing/modernising them would be a great way to learn.
For example, we've had plans for a long time to make xfs_fsr (the
online defragmenter) more intelligent and able to solve issues we
know exist but never had the time to fix. For example:
- explicit control of locality for groups of files
- ability to defragment only portions of files rather than
just whole files
- defragmenting free space
- enhanced/faster filesystem scanning
In just those four things, there are new kernel interfaces that are
required, interaction with other community members that are adding
code whose functionality you'd need to build upon, code
modernisation/factoring/enhancement, partial and full filesystem
structural analysis to determine optimal data movement to solve
multiple goals, test code for the new interfaces and each new
defragmentation goal, etc.
A project like this allows you to start by classifying and
understanding the current high level behaviour of both the fileystm
and the utility, then it's limitations and it's problems, then
determine the best solutions to the problems, and then implement the
solutions. The work can also be broken up into multiple independent
parts, which is useful for a team that is doing the work.
The main thing is that you are not going to be able to do this in
isolation. Each step of the process needs review and feedback from
the community, otherwise we'll can end up with code that nobody wants
or can use. You're going to need to pick the brains of community
people to understand the algorithms and their deficiencies,
and for us to pick holes in your solutions to those deficiencies
to improve the solutions we end up implementing.
To illustrate this with an example, I'll again point you to Brian's
sparse inode allocation patchset from this morning. The idea behind
that patchset was originally documented back in 2008 here:
http://xfs.org/index.php/Improving_inode_Caching#Single_Block_Inode_Allocation
and it's taken us a long time to:
a) understand exactly what is required to implement such
functionality; and
b) get the pre-requisite infrastructure in place to be able
to start implementing the solution.
IOWs, we've talked about the design for some time and the code Brian
posted is an early prototype of the solution we've iterated over.
There are lots of open discussion points that the prototype has
uncovered, and so we'll continue to iterate the
design/prototype/review cycle on the mailing list until we have code
of production quality. That is likely to still take a couple months
to get the functionality to the point where it can be merged.
I'm mentioning this because it will give you some insight into the
processes we use for solving problems and getting those changes into
the upstream code base. Keep in mind, though, that the bar isn't
quite as high for userspace code as it is for kernel code - that's
one of the reasons why I'm suggesting that improving userspace
utilities is a good place to start.
If defragmetnation and layout optimisation doesn't really interest
you, I can suggest other features we would like to have that require
similar levels of development work for both kernel and userspace
like filesystem shrinking or reverse block mapping for error
recovery purposes, or ....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 2+ messages in thread