Re: [PATCH 7/9] exofs: mkexofs

[Boaz Harrosh]

Andrew Morton wrote:
> On Tue, 16 Dec 2008 17:33:48 +0200
> Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> 
>> We need a mechanism to prepare the file system (mkfs).
>> I chose to implement that by means of a couple of
>> mount-options. Because there is no user-mode API for committing
>> OSD commands. And also, all this stuff is highly internal to
>> the file system itself.
>>
>> - Added two mount options mkfs=0/1,format=capacity_in_meg, so mkfs/format
>>   can be executed by kernel code just before mount. An mkexofs utility
>>   can now be implemented by means of a script that mounts and unmount the
>>   file system with proper options.
> 
> Doing mkfs in-kernel is unusual.  I don't think the above description
> sufficiently helps the uninitiated understand why mkfs cannot be done
> in userspace as usual.  Please flesh it out a bit.

There are a few main reasons.
- There is no user-mode API for initiating OSD commands. Such a subsystem
  would be hundredfold bigger then the mkfs code submitted. I think it would be
  hard and stupid to maintain a complex user-mode API just for creating
  a couple of objects and writing a couple of on disk structures.
- I intend to refactor the code further to make use of more super.c services,
  so to make this addition even smaller. Also future direction of raid over
  multiple objects will make even more kernel infrastructure needed which
  will need even more user-mode code duplication.
- I anticipate problems that are not yet addressed in this body of work
  but will be in the future, mainly that a single OSD-target (lun) can
  be shared by lots of FSs, and a single FS can span many OSD-targets.
  Some central management is much easier to do in Kernel.

> 
> What are the dependencies for this filesystem code?  I assume that it
> depends on various block- and scsi-level patches?  Which ones, and
> what is their status, and is this code even compileable without them?
> 

This OSD-based file system is dependent on the open-osd initiator library
code that I've submitted for inclusion for 2.6.29. It has been sitting
in linux-next for a while now, and has not been receiving any comments
for the last two updated patchsets I've sent to scsi-misc/lkml. However
it has not yet been submitted into Jame's scsi-misc git tree, and James
is the ultimate maintainer that should submit this work. I hope it will
still be submitted into 2.6.29, as this code is totally self sufficient
and does not endangers or changes any other Kernel subsystems.
(All the needed ground work was already submitted to Linus since 2.6.26)
So why should it not?

Once the open-osd initiator library is accepted this file system
could be accepted. I was hoping as a 2.6.30 time frame. (One Kernel
after the open-osd library)

> Thanks.

Thank you dear Andrew for your most valuable input.

I will constify all the const needed code. will fix the global name space
litter, will inline the macros and lower case the inlines. Will remove
the typedefs.

I will reply to individual patches, I have a couple of questions. But
all your comments are right and I will take care of them.

When, if, all is fixed, through which tree/maintainer can exofs be submitted?

Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/