Messages in this thread | | | From | Shawn Leas <> | Subject | FW: How do I do it? (was Re: Accountability) | Date | Fri, 17 Sep 1999 10:07:42 -0500 |
| |
Here's some info.
-----Original Message----- From: Andreas Dilger [mailto:adilger@enel.ucalgary.ca] Sent: Thursday, September 16, 1999 1:27 AM To: linux-kernel@vger.rutgers.edu Subject: How do I do it? (was Re: Accountability)
On a more positive side of the "Accountability" thread, let's see what CAN be done to get things into the kernel... I'm a relative newcomer here (too much traffic for my liking before I had a kernel patch to care about), so bear with me.
I have written a kernel patch which will allow resizing of an ext2 filesystem while it is mounted (online-ext2 is available at my web page: http://www-mddsp.enel.ucalgary.ca/People/adilger/online-ext2/
1) My kernel patch does the minimal work it needs to, and the rest is done as user-space utilities, which I think is the desirable way to go, as we don't wan't the kernel to be able to do a mke2fs necessarily. So far so good? 2) I re-used what existing kernel code I could, made it more generic in some cases, to handle what I needed to do. Presumably this is the correct way to go? 3) I have read about formatting of code for the kernel, and have tried to follow them. Would patches be rejected for having too many comments? 4) There are some known "issues" in the patch (e.g. it turns off quota checking while not having the lock on the filesystem for a "brief instant" because it is calling a function which grabs the superblock lock itself). Is this "permitted", considering the combination of quotas, frequency of filesystem resize, and a "one-line" chance of being interrupted before getting the superblock lock again is considered small enough to justify not making more changes to the kernel? 5) Since the userspace tools aren't 100% ready for public consumption, is there any chance of getting the patch into 2.3.x? I wanted to have the user code ready before trying to get the patch into the mainstream kernel (to avoid more patches to the kernel), but in my testing the kernel code is ready for use. The resize functions added by the patch sits totally off the main code path, so do not have any real performance impact at all if they are added. 6) With a new feature like this, would it be required to have an option to turn it on/off via menuconfig? The patch will add a useful capability to the kernel even if people don't have the user-space tools required for full functionality (ie an unmodified "mount" command can do wonders for you if required). However, to really get use out of this patch, you need to be able to resize your underlying device size via md or hardware RAID, or most likely LVM.
Trying to be a good l-k participant...
Cheers, Andreas -- Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |