Re: fdisk implementation [read this before deciding what to do]
Update: After additional consideration and some discussion on the Dragonfly IRC, etc, we have decided to go ahead and put this project on the back burner for now. For one, it may be a while before we can get around to adding disklabel64 support. Also, the Dragonfly community seems to want built in interactive mode and compatibility with the existing disklabel and fdisk tools. Our tools are designed specifically to be run under front end scripts and are not interactive or command line compatible with the existing tools. Sorry about the delay in following up on this. Ok, sorry to hear that. Basically this means I'll go back to work myself Offtopic: BTW, is the IRC channel listed anywhere on the page or in any ailing list message ? I did not know that it existed.
Re: fdisk implementation [read this before deciding what to do]
Jost Tobias Springenberg schrieb: Offtopic: BTW, is the IRC channel listed anywhere on the page or in any ailing list message ? I did not know that it existed. Yeah, http://www.dragonflybsd.org/mailinglists/ Sascha -- http://yoyodyne.ath.cx
Re: fdisk implementation [read this before deciding what to do]
On Tue, March 10, 2009 12:17 pm, Jost Tobias Springenberg wrote: BTW, is the IRC channel listed anywhere on the page or in any ailing list message ? I did not know that it existed. It's mentioned now on the mailing lists page on the dragonflybsd.org website. I added it last week, which is why you may not have seen mention of it.
Re: fdisk implementation [read this before deciding what to do]
On Tue, Feb 17, 2009 at 05:54:40PM +, Jost Tobias Springenberg wrote: Is there any chance of this moving forward ? As mentioned in my previous post I really need this feature :). If you need any help or the like I would be more than happy to help and get this project on track again! Otherwise I might go back to were I started off and finish a new fdisk with less features myself. Update: After additional consideration and some discussion on the Dragonfly IRC, etc, we have decided to go ahead and put this project on the back burner for now. For one, it may be a while before we can get around to adding disklabel64 support. Also, the Dragonfly community seems to want built in interactive mode and compatibility with the existing disklabel and fdisk tools. Our tools are designed specifically to be run under front end scripts and are not interactive or command line compatible with the existing tools. Sorry about the delay in following up on this.
Re: fdisk implementation [read this before deciding what to do]
Ok, time for me to reply again :). I started developing on this, as I mentioned in the first post. I have a first working interface draft and started to work on the real fdisk implementation by moving in core code from the dfly fdisk implementation I stopped development however when I read about Vincet's post, as I don't want to do unnecessary development work. I therefore suggest we first check what might come out of this, and I declare myself willing to help wherever needed. If it turns out that the tool is not releasable for some reason whatsoever I will continue working on the fdisk implementation. Does this sound reasonable ? Greetings, Tobias -- Jost Tobias Springenberg jspri...@uos.de If you plan to send me any personal or sensitive information please use GnuPG! My public key can be found at: http://www-lehre.informatik.uos.de/~jspringe/jspringe.gpg
Re: fdisk implementation [read this before deciding what to do]
On Wed, Jan 07, 2009 at 11:38:45PM -0800, Matthew Dillon wrote: :I could put up a binary if anybody wants to play with it. If you guys :are interested in taking it over, making it an official part of :Dragonfly, and updating it for the new disk labels, etc, we were :considering going ahead and releasing the source. If not, we will :probably hold off and release it later on as part of some other projects :after we get a chance to finish it ourselves. But that might be :a while. Well, it sounds quite interesting to me though if it does not yet support disklabel64's maybe I could get you guys to add that before submitting it. The boot1/boot2 images have recently changed in order to support generating different sets for 32 bit disklabels and 64 bit disklabels. It would have to be open-sourced with a BSD style license if you want to submit it. We might cringe a bit if it needs a manual page written plus a lot of code cleanup. -Matt Matthew Dillon dil...@backplane.com Yes, if you decide you want to make it an official part of DF we were planning to put it under the BSD license. I don't think there is much code cleanup needed. Mostly the addition of the extra features. At the time Chet originally ported partition to DF, the disklabel64 headers were not finished yet in DF. He wants to go ahead and separate the fdisk portion out into a separate tool (Which will be easy - The code is modular) rather than keeping it as a combined tool that does the job of disklabel and fdisk. He wants to do that first, then we can give you a copy of the source (and binary if you want) to the fdisk tool to look over and see what you think. If you like what you see and want to include the tools, Chet said he will look into adding disklabel64 support. Also, I will go ahead and work on the planned command line changes I mentioned first so that I can write an initial manual. If you look over fdisk and give me a confirmation that you want to include the tools in DF and take over maintenance on them, we will bump the priority up on preparing them for you. Otherwise, we are going to hold off on doing more work on and officially releasing them until they are needed as part of some other projects we are working on. So the evaluation copy of fdisk we give you will not yet be under the BSD license.
Re: fdisk implementation [read this before deciding what to do]
On Fri, Jan 09, 2009 at 04:12:45AM +0100, Simon 'corecode' Schubert wrote: Vincent Stemen wrote: If you like what you see and want to include the tools, Chet said he will look into adding disklabel64 support. Also, I will go ahead and work on the planned command line changes I mentioned first so that I can write an initial manual. I think it is important that whatever tool we use, it should have some sort of interactive mode (like fdisk and disklabel have). This can be implemented in shell/editor, however. cheers simon Yes, in the traditional layered Unix approach, this tool was specifically designed to be easier to automate and to write interactive front ends than the existing tools. It would probably be easy enough to add a simple interactive mode to the tool itself, but I hesitate to do that because, as you mentioned, I can do the same thing with a shell script, making it easy to tune the interactive behavior and to have multiple different interfaces that are as simple or as sophisticated as you want. If it ends up being accepted into DF, I could probably try to make the time to go ahead and write an initial interactive front end in Perl or shell script for you. Also, I mentioned having a separate partitioning library in my original post, so that UIs could be written in C and link directly with the library. However, we have decided against distributing it that way for maintainability of the UIs. A library can easily be made out of the functions but I would not recommend it. If the UIs call on the command line tool, then you have a single point of maintenance and they do not have to be updated and recompiled if there is a change to the actual partitioning code. Unless, of course, the command line changes in an incompatible way. Which is why I planned to finalize the command line interface as much as possible prior to an official release. Also, these tools work on other BSD's (FreeBSD and NetBSD so far) which have variations in the partitioning API. The idea is for the UIs to work across the board without change.
Re: fdisk implementation [read this before deciding what to do]
:I could put up a binary if anybody wants to play with it. If you guys :are interested in taking it over, making it an official part of :Dragonfly, and updating it for the new disk labels, etc, we were :considering going ahead and releasing the source. If not, we will :probably hold off and release it later on as part of some other projects :after we get a chance to finish it ourselves. But that might be :a while. Well, it sounds quite interesting to me though if it does not yet support disklabel64's maybe I could get you guys to add that before submitting it. The boot1/boot2 images have recently changed in order to support generating different sets for 32 bit disklabels and 64 bit disklabels. It would have to be open-sourced with a BSD style license if you want to submit it. We might cringe a bit if it needs a manual page written plus a lot of code cleanup. -Matt Matthew Dillon dil...@backplane.com
Re: fdisk implementation [read this before deciding what to do]
On Wed, Dec 17, 2008 at 09:49:21AM -0800, Matthew Dillon wrote: A few possible gotchas regarding fdisk and disklabels. DragonFly has a 64 bit disklabel feature now (disklabel64), as well as gpt support, but lacks boot support for either. I think the fdisk utility needs to be separate from the disklabel utility. Also as HAMMER moves more into the mainstream the recommended partitioning scheme is to only have two partitions... a small UFS /boot, and everything else in a single HAMMER root. -Matt We noticed the problems with the existing BSD partitioning tools and, several years ago, my brother wrote a replacement that we have been using since. I figured now is the time to chime in since, apparently you guys are about to decide on a new direction for these tools. I also liked the user interface to cfdisk but Sascha hit the nail on the head when he mentioned the interactive tools not being scriptable. I don't think they follow the Unix layered philosophy in that sense. And, of course, partitioning tools that I have seen from the Linux world such as cfdisk are licensed as GPL rather than BSD, which I don't think is appropriate for a core BSD sys-admin utility if it can be avoided. We have been using our tool for the last several years on NetBSD, FreeBSD, and DragonflyBSD. We have been calling it *partition*, because it is an intuitive name for its function (creates both bsd partitions as well as PC partitions (slices)), but that name is not set in concrete. If it became an official replacement for fdisk in DF, I guess it could be named *fdisk* but I never thought that was really a good name now days since we are dealing with more than fixed disks. It is command line based (completely non-interactive) and designed to be easy to use manually, yet extremely script friendly so that you can use it in automated installation tools as well as put any kind of UI on it you choose, even simple interactive shell scripts. It is also layered into a C library so that C programs do not have to do a forkexec of a command line tool for every function. The code is clean and simple to work with. It does both partitioning and disk labeling. And each function is stand alone, so you run it once for each change, (e.g. add a single partition, etc). Here is the usage and some examples. usage: partition --command [/dev/device] [arg ,,,] #partition --help #partition --list-params /dev/ad0 #partition --list-slice /dev/ad0 1 #partition --list-slices /dev/ad0 #partition --list-slice-free-space /dev/ad0 #partition --list-slice-types #partition --del-slice /dev/ad0 1 #partition --list-label /dev/ad0 1 #partition --list-partition /dev/ad0 1 a #partition --add-partition /dev/ad0 1 a all auto #partition --add-partition /dev/ad0 1 a 200mb auto #partition --add-partition /dev/ad0 1 a 3 1 #partition --set-partition-type /dev/ad0 1 a 4.2BSD #partition --set-partition-type /dev/ad0 1 b swap #partition --set-disklabel-params /dev/ad0 1 disk name #partition --set-disklabel-params /dev/ad0 1 label label #partition --new-label /dev/ad0 1 #partition --check-label /dev/ad0 1 #partition --init-boot-sect /dev/ad0 The output is all script friendly, so that it can be sourced directly from a shell script. Example: # partition --list-slices /dev/ad10 slice1_type=DragonFly/FreeBSD/NetBSD/386BSD slice1_stat=active slice1_size_in_mb=305245.3125 slice1_size_in_blocks=625142385 slice1_starting_block=63 slice1_ending_block=625142447 slice1_type_in_hex=a5 slice1_flag_in_hex=80 slice1_starting_cyl=0 slice1_starting_sec=1 slice1_starting_head=1 slice2_stat=available slice3_stat=available slice4_stat=available We planned to eventually release it under the BSD license but have never released it yet because of several reasons. (1) The command line structure is temporary. The current CL requires an exact order of arguments, which is not much of a problem for user interfaces or scripts, but is less CL friendly and easier to make a mistake. I planned to write a new CL parser that is more consistent to some of the other tools we have written that do not depend on the order of the arguments. i.e. partition command setting=value setting=value Examples: partition list-slices dev=/dev/ad0 partition set-partition-type dev=/dev/ad0 slice=1 partition=a type=4.2BSD I also plan to have short and abbreviated forms of the commands. (2) In reference to what Matt mentioned, it does not yet support Some of DF's new features such as 64 bit disk labels. (3) I think there have also been some other changes in DF disk label that still require
Re: fdisk implementation
A few possible gotchas regarding fdisk and disklabels. DragonFly has a 64 bit disklabel feature now (disklabel64), as well as gpt support, but lacks boot support for either. I think the fdisk utility needs to be separate from the disklabel utility. Also as HAMMER moves more into the mainstream the recommended partitioning scheme is to only have two partitions... a small UFS /boot, and everything else in a single HAMMER root. -Matt
Re: fdisk implementation
On Wed, 9 Jul 2008 10:27:49 -0700 Freddie Cash [EMAIL PROTECTED] wrote: On Tue, Jul 8, 2008 at 10:35 AM, Matthew Dillon [EMAIL PROTECTED] wrote: :just a quick sidenote... while I decided to finally play around with hammer :I had to fiddle around with dragonfly's fdisk implementation and I think it is a mess! :The menu driven mode is horrible, and absolutely not self explaining. :We should definitely adapt the OpenBSD or newer FreeBSD version. :Is there any reason there could occur bigger problems with this ? :Otherwise I'm actually willing to try to port it over during my semester break, :because I really believe it is necessary to do this. :If there is any special super mode I missed about the fdisk we are using right now just let me know! :Regards, :Tobias : :-- :Jost Tobias Springenberg [EMAIL PROTECTED] We could probably use a new fdisk, I think this would be a good project. You may want to have a look at http://www.freshports.org/sysutils/sfdisk/ This is the fdisk tool used in sysinstall, and has a decent interface. It's similar to cfdisk from the Linux-world (but nicer to use IMO). -- Freddie Cash [EMAIL PROTECTED] Ok I guess I will take a look at it tonight and also search for alternatives. I'll have 2 weeks of time during the next 2 months so it should be possible to finish this. Question to the sfdisk, I am not an expert regarding FreeBSD code, but doesn't sfdisk depend on some internal FreeBSD disk abstractions ?? Greetings, Tobi -- Jost Tobias Springenberg [EMAIL PROTECTED] If you plan to send me any personal or sensitive information please use GnuPG! My public key can be found at: http://www-lehre.informatik.uos.de/~jspringe/jspringe.gpg
Re: fdisk implementation
On Thu, Jul 10, 2008 at 3:43 AM, Jost Tobias Springenberg [EMAIL PROTECTED] wrote: On Wed, 9 Jul 2008 10:27:49 -0700 Freddie Cash [EMAIL PROTECTED] wrote: On Tue, Jul 8, 2008 at 10:35 AM, Matthew Dillon We could probably use a new fdisk, I think this would be a good project. You may want to have a look at http://www.freshports.org/sysutils/sfdisk/ This is the fdisk tool used in sysinstall, and has a decent interface. It's similar to cfdisk from the Linux-world (but nicer to use IMO). Ok I guess I will take a look at it tonight and also search for alternatives. I'll have 2 weeks of time during the next 2 months so it should be possible to finish this. Question to the sfdisk, I am not an expert regarding FreeBSD code, but doesn't sfdisk depend on some internal FreeBSD disk abstractions ?? Sorry, couldn't tell you about that. I'm just a user of sfdisk, don't know anything about its internals. -- Freddie Cash [EMAIL PROTECTED]
Re: fdisk implementation
Freddie Cash wrote: On Thu, Jul 10, 2008 at 3:43 AM, Jost Tobias Springenberg Sorry, couldn't tell you about that. I'm just a user of sfdisk, don't know anything about its internals. Apparently it doesn't depend on much: niobe% ldd /usr/local/sbin/sfdisk /usr/local/sbin/sfdisk: libdialog.so.6 = /usr/lib/libdialog.so.6 (0x28086000) libc.so.7 = /lib/libc.so.7 (0x280a3000) libncurses.so.7 = /lib/libncurses.so.7 (0x281a) But of course it is deficient in that it doesn't see logical partitions. With it you can edit 4 primary partitions, period. No logical, no bsd partitions. In other words, it is of very limited utility, in my opinion. A good partitioning tool is still lacking for FreeBSD, able to do at least what Linux cfdisk does so simply. I suppose the geometry problems which plague FreeBSD sysinstall are also present on sfdisk. -- Michel Talon
Re: fdisk implementation
On Tue, Jul 8, 2008 at 10:35 AM, Matthew Dillon [EMAIL PROTECTED] wrote: :just a quick sidenote... while I decided to finally play around with hammer :I had to fiddle around with dragonfly's fdisk implementation and I think it is a mess! :The menu driven mode is horrible, and absolutely not self explaining. :We should definitely adapt the OpenBSD or newer FreeBSD version. :Is there any reason there could occur bigger problems with this ? :Otherwise I'm actually willing to try to port it over during my semester break, :because I really believe it is necessary to do this. :If there is any special super mode I missed about the fdisk we are using right now just let me know! :Regards, :Tobias : :-- :Jost Tobias Springenberg [EMAIL PROTECTED] We could probably use a new fdisk, I think this would be a good project. You may want to have a look at http://www.freshports.org/sysutils/sfdisk/ This is the fdisk tool used in sysinstall, and has a decent interface. It's similar to cfdisk from the Linux-world (but nicer to use IMO). -- Freddie Cash [EMAIL PROTECTED]
fdisk implementation
Hi all, just a quick sidenote... while I decided to finally play around with hammer I had to fiddle around with dragonfly's fdisk implementation and I think it is a mess! The menu driven mode is horrible, and absolutely not self explaining. We should definitely adapt the OpenBSD or newer FreeBSD version. Is there any reason there could occur bigger problems with this ? Otherwise I'm actually willing to try to port it over during my semester break, because I really believe it is necessary to do this. If there is any special super mode I missed about the fdisk we are using right now just let me know! Regards, Tobias -- Jost Tobias Springenberg [EMAIL PROTECTED] If you plan to send me any personal or sensitive information please use GnuPG! My public key can be found at: http://www-lehre.informatik.uos.de/~jspringe/jspringe.gpg
Re: fdisk implementation
:Hi all, :just a quick sidenote... while I decided to finally play around with hammer :I had to fiddle around with dragonfly's fdisk implementation and I think it is a mess! :The menu driven mode is horrible, and absolutely not self explaining. :We should definitely adapt the OpenBSD or newer FreeBSD version. :Is there any reason there could occur bigger problems with this ? :Otherwise I'm actually willing to try to port it over during my semester break, :because I really believe it is necessary to do this. :If there is any special super mode I missed about the fdisk we are using right now just let me know! :Regards, :Tobias : :-- :Jost Tobias Springenberg [EMAIL PROTECTED] We could probably use a new fdisk, I think this would be a good project. -Matt Matthew Dillon [EMAIL PROTECTED]
