Discussion:
My project wish-list for the next 12 months
(too old to reply)
Scott Long
2004-12-01 22:02:40 UTC
Permalink
All,

I know that I said last month that we were going to stop promising
specific features for the next major release. However, I'd like to
throw out a list of things that would be really nice to have in the
future, whether its 6.0 or 7.0 or whatever. Most of these tasks are
not trivial, but I hope that talking about them will encourage some
interest. These are in no particular priority order. I'd also be
thrilled if someone wanted to dress this list up in docbook and add
it to the webpage. While this is just my personal list, I'd welcome
other additions to it (in the sense of significant projects, not just
individual PRs or bug fixes that one might be interested in).

1. Keyboard multiplexer. We are running into problems with making
ps/2 and USB/bluetooth keyboards work together and work with KVMs.
Having a virtual keyboard device that multiplexes the various real
keyboard devices and handles hotplug can solve this mess pretty
effectively. I know that there has been a lot of talk about this on
mailing lists recently but I don't know how much progress is being made
so I'm listing it here.

2. New installer. I know some people still consider this a joke, but
the reality is that sysinstall is no longer state of the art. It's
fairly good at the simple task that it does, but it's becoming harder
and harder to fix bugs and extend functionality in it. It's also
fairly unfriendly to those of us who haven't been using it since 1995.
The DFly folks have some very interesting work in this area
(www.bsdinstaller.com) and it would be very good to see if we can
collaborate with them on it.

3. Native PCI Express support. I keep on hoping to take care of this,
but I never seem to have the time to get past designing it. This task
includes 3 parts that are mostly independent. The first is support for
the extended PCI config space and memio access method, the second is
MSI, and the third is link QOS management. If anyone is interested
here, please let me know.

4. Journaled filesystem. While we can debate the merits of speed and
data integrety of journalling vs. softupdates, the simple fact remains
that softupdates still requires a fsck run on recovery, and the
multi-terabyte filesystems that are possible these days make fsck a very
long and unpleasant experience, even with bg-fsck. There was work at
some point at RPI to add journaling to UFS, but there hasn't been much
status on that in a long time. There have also been proposals and
works-in-progress to port JFS, ReiserFS, and XFS. Some of these efforts
are still alive, but they need to be seen through to completion. But at
the risk of opening a can of worms here, I'll say that it's also
important to explore non-GPL alternatives.

5. Clustered FS support. SANs are all the rage these days, and
clustered filesystems that allow data to be distributed across many
storage enpoints and accessed concurrently through the SAN are very
powerful. RedHat recently bought Sistina and re-opened the GFS source
code, so exploring this would be very interesting.

6. Overhaul CAM, add iSCSI. CAM is very parallel-SCSI centric right
now. I have some work-in-progress in Perforce to address this, but it's
pretty minimal. The parallel SCSI knowledge needs to be separated out
and the stack need to be able to cleanly deal with iSCSI, SCSI, SAS, and
maybe even ATA transports. There is a Lucent implementation of iSCSI
for FreeBSD 4.x that could be a useful reference, though it's a
monolithic stack that doesn't really address the shortcomings of CAM.
Having iSCSI infrastructure that supported both hardware and software
implementations would be ideal.
Andre Oppermann
2004-12-01 22:14:39 UTC
Permalink
Scott Long wrote:
> All,
>
> I know that I said last month that we were going to stop promising
> specific features for the next major release. However, I'd like to
> throw out a list of things that would be really nice to have in the
> future, whether its 6.0 or 7.0 or whatever. Most of these tasks are
> not trivial, but I hope that talking about them will encourage some
> interest. These are in no particular priority order. I'd also be
> thrilled if someone wanted to dress this list up in docbook and add
> it to the webpage. While this is just my personal list, I'd welcome
> other additions to it (in the sense of significant projects, not just
> individual PRs or bug fixes that one might be interested in).
>
> 1. Keyboard multiplexer. We are running into problems with making
> ps/2 and USB/bluetooth keyboards work together and work with KVMs.
> Having a virtual keyboard device that multiplexes the various real
> keyboard devices and handles hotplug can solve this mess pretty
> effectively. I know that there has been a lot of talk about this on
> mailing lists recently but I don't know how much progress is being made
> so I'm listing it here.
>
> 2. New installer. I know some people still consider this a joke, but
> the reality is that sysinstall is no longer state of the art. It's
> fairly good at the simple task that it does, but it's becoming harder
> and harder to fix bugs and extend functionality in it. It's also
> fairly unfriendly to those of us who haven't been using it since 1995.
> The DFly folks have some very interesting work in this area
> (www.bsdinstaller.com) and it would be very good to see if we can
> collaborate with them on it.
>
> 3. Native PCI Express support. I keep on hoping to take care of this,
> but I never seem to have the time to get past designing it. This task
> includes 3 parts that are mostly independent. The first is support for
> the extended PCI config space and memio access method, the second is
> MSI, and the third is link QOS management. If anyone is interested
> here, please let me know.
>
> 4. Journaled filesystem. While we can debate the merits of speed and
> data integrety of journalling vs. softupdates, the simple fact remains
> that softupdates still requires a fsck run on recovery, and the
> multi-terabyte filesystems that are possible these days make fsck a very
> long and unpleasant experience, even with bg-fsck. There was work at
> some point at RPI to add journaling to UFS, but there hasn't been much
> status on that in a long time. There have also been proposals and
> works-in-progress to port JFS, ReiserFS, and XFS. Some of these efforts
> are still alive, but they need to be seen through to completion. But at
> the risk of opening a can of worms here, I'll say that it's also
> important to explore non-GPL alternatives.
>
> 5. Clustered FS support. SANs are all the rage these days, and
> clustered filesystems that allow data to be distributed across many
> storage enpoints and accessed concurrently through the SAN are very
> powerful. RedHat recently bought Sistina and re-opened the GFS source
> code, so exploring this would be very interesting.
>
> 6. Overhaul CAM, add iSCSI. CAM is very parallel-SCSI centric right
> now. I have some work-in-progress in Perforce to address this, but it's
> pretty minimal. The parallel SCSI knowledge needs to be separated out
> and the stack need to be able to cleanly deal with iSCSI, SCSI, SAS, and
> maybe even ATA transports. There is a Lucent implementation of iSCSI
> for FreeBSD 4.x that could be a useful reference, though it's a
> monolithic stack that doesn't really address the shortcomings of CAM.
> Having iSCSI infrastructure that supported both hardware and software
> implementations would be ideal.

Seeing all this storage related stuff is very interesting because I just
stumbled across a company making a new digital Cinematography system that
has 8Mpix and they say that using this in a day's worth shooting they end
up with up to 6.63TB of raw digigal footage. In the end this is 398TB for
an average feature movie. The camera delivers the images over
quad-infiniband to the recording system at 400MB/s. Pretty impressive.

http://www.dalsa.com/dc/workflow/storage.asp

--
Andre
Michael Nottebrock
2004-12-01 23:14:31 UTC
Permalink
On Wednesday, 1. December 2004 23:14, Andre Oppermann wrote:
> Scott Long wrote:
> > All,
> >
> > I know that I said last month that we were going to stop promising
> > specific features for the next major release. However, I'd like to
> > throw out a list of things that would be really nice to have in the
> > future, whether its 6.0 or 7.0 or whatever. Most of these tasks are
> > not trivial, but I hope that talking about them will encourage some
> > interest. These are in no particular priority order. I'd also be
> > thrilled if someone wanted to dress this list up in docbook and add
> > it to the webpage. While this is just my personal list, I'd welcome
> > other additions to it (in the sense of significant projects, not just

Suspend-to-Disk support. I remember somebody thinking aloud about howit would
be possible to implement it, Linux has got it recently, and it's one heck of
a feature for mobile computing (but not only).

--
,_, | Michael Nottebrock | ***@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Ryan Sommers
2004-12-01 23:10:57 UTC
Permalink
Scott Long said:
> 2. New installer. I know some people still consider this a joke, but
> the reality is that sysinstall is no longer state of the art. It's
> fairly good at the simple task that it does, but it's becoming harder
> and harder to fix bugs and extend functionality in it. It's also
> fairly unfriendly to those of us who haven't been using it since 1995.
> The DFly folks have some very interesting work in this area
> (www.bsdinstaller.com) and it would be very good to see if we can
> collaborate with them on it.

I've spent a good deal of time taking notes and diagrams of what I wanted
from a new installer. However, time constraints have kept me from actually
putting any of it to code yet.

I've looked at the DFly installed quite a bit and I like what it offers,
however, I have a few complaints with it. Quite honestly I wasn't
impressed with the code.

Another issue I had with the dfly installer was one point I believe needs
to be central to any next-gen installer. Internationalisation. My idea of
an installer front-end would use a dynamically loadable language library.
All resources of the front-end (ie strings, images, etc) would be packaged
into a seperate language-pack. These language-packs can then be grouped
together into a language library. A few basic packs would be distributed
with the default library but other libraries could easily be substituted
to make localized distribution sets with little trouble.

The benefit of this is that instead of translating the code you would only
need to translate the language-(pack|library). I think this would greatly
simplify translation and make a seperation between language and the
front-end code.

This is where my complaint with Dfly comes in, upon reading the source,
there are string constants everywhere. Perhaps I am missing something, but
this means that in order to supply localization support much work would
need to be done to find some scheme that doesn't mean translating the
source.

I have quite a bit of notes on seperation and even down to specific
methods and sub-libraries necessary for the back-end. Perhaps if I have
some time soon I'll put it into a PDF somewhere.

Has anyone else put much thought into this?

--
Ryan Sommers
***@gamersimpact.com
Kris Kennaway
2004-12-01 23:20:52 UTC
Permalink
On Wed, Dec 01, 2004 at 04:10:57PM -0700, Ryan Sommers wrote:

> Another issue I had with the dfly installer was one point I believe needs
> to be central to any next-gen installer. Internationalisation.

Careful not to pile on so many wishes that achieving anything becomes
impossible. Our current installer doesn't do this, so it's not a hard
requirement that a better installer should.

Kris
Scott Long
2004-12-01 23:19:05 UTC
Permalink
Kris Kennaway wrote:
> On Wed, Dec 01, 2004 at 04:10:57PM -0700, Ryan Sommers wrote:
>
>
>>Another issue I had with the dfly installer was one point I believe needs
>>to be central to any next-gen installer. Internationalisation.
>
>
> Careful not to pile on so many wishes that achieving anything becomes
> impossible. Our current installer doesn't do this, so it's not a hard
> requirement that a better installer should.
>
> Kris

Internationalization is actually quite important, and is not easy to
bolt on after the fact but is fairly easy to program to once the core is
in place. The fact that sysinstall doesn't have it makes it no less
important. Now this isn't a reason to reject the DFly work, but it
could certainly be a good area for someone to contribute.

Scott
Jose M Rodriguez
2004-12-03 09:50:50 UTC
Permalink
El Jueves, 2 de Diciembre de 2004 00:19, Scott Long escribió:
> Kris Kennaway wrote:
> > On Wed, Dec 01, 2004 at 04:10:57PM -0700, Ryan Sommers wrote:
> >>Another issue I had with the dfly installer was one point I believe
> >> needs to be central to any next-gen installer.
> >> Internationalisation.
> >
> > Careful not to pile on so many wishes that achieving anything
> > becomes impossible. Our current installer doesn't do this, so it's
> > not a hard requirement that a better installer should.
> >
> > Kris
>
> Internationalization is actually quite important, and is not easy to
> bolt on after the fact but is fairly easy to program to once the core
> is in place. The fact that sysinstall doesn't have it makes it no
> less important. Now this isn't a reason to reject the DFly work, but
> it could certainly be a good area for someone to contribute.
>
> Scott
>

Sure. I can confirm this. But this issue must be take with care.

1.- This is an overall effort that, IMHO, must begin with a real i18n
ports work. Actual ports doesn't have a well defined i18n behavior.

2.- this covers several unrelated issues:
- i18n, lang related issues. iso8859-1, unicode, arabic ...
- l10n, locale related issues (country specific).
- base system oper (try hack arround loader with a foreing keyboard).

About the base system, I have really bad experiences with i18n/locale
support in boot/system works. This must be a low priority task.

But I'll be really glad to see some basic foreing keyboard/console
support in boot/loader as:
boot> keyb sp

--
josemi
Jason C. Wells
2004-12-01 23:29:10 UTC
Permalink
--On Wednesday, December 01, 2004 3:02 PM -0700 Scott Long
<***@freebsd.org> wrote:

> 5. Clustered FS support. SANs are all the rage these days, and
> clustered filesystems that allow data to be distributed across many
> storage enpoints and accessed concurrently through the SAN are very
> powerful. RedHat recently bought Sistina and re-opened the GFS source
> code, so exploring this would be very interesting.

This sounds very close to OpenAFS. I don't know what distinguishes a SAN
from other types of NAS. OpenAFS does everything you mentioned in the
above paragraph. OpenAFS _almost_ works on FreeBSD right now.

Later,
Jason C. Wells
Kris Kennaway
2004-12-01 23:38:52 UTC
Permalink
On Wed, Dec 01, 2004 at 03:29:10PM -0800, Jason C. Wells wrote:
> --On Wednesday, December 01, 2004 3:02 PM -0700 Scott Long
> <***@freebsd.org> wrote:
>
> >5. Clustered FS support. SANs are all the rage these days, and
> >clustered filesystems that allow data to be distributed across many
> >storage enpoints and accessed concurrently through the SAN are very
> >powerful. RedHat recently bought Sistina and re-opened the GFS source
> >code, so exploring this would be very interesting.
>
> This sounds very close to OpenAFS. I don't know what distinguishes a SAN
> from other types of NAS. OpenAFS does everything you mentioned in the
> above paragraph. OpenAFS _almost_ works on FreeBSD right now.

I'd be very interested to try using this for package builds, btw.
Currently I have to rsync a lot of data to the remote build clients,
which takes a very long time.

Kris
Brad Knowles
2004-12-02 00:23:57 UTC
Permalink
At 3:38 PM -0800 2004-12-01, Kris Kennaway quoted Jason C. Wells:

>> This sounds very close to OpenAFS. I don't know what distinguishes a SAN
>> from other types of NAS. OpenAFS does everything you mentioned in the
>> above paragraph. OpenAFS _almost_ works on FreeBSD right now.
>
> I'd be very interested to try using this for package builds, btw.
> Currently I have to rsync a lot of data to the remote build clients,
> which takes a very long time.

It's interesting that you mention this. I've been giving some
thought to how I might be able to dive in and start seriously working
on building my UltraSPARC cluster (based on the four U10 clones I
have already, plus as many U5s as I can throw into the mix), and I
was hoping to find a better solution than NFS, and AFS/Coda/OpenAFS
was tops of my list of alternatives to consider.

In particular, if I can get this thing working reasonably well,
I'd like to turn this into a package building cluster for
FreeBSD/UltraSPARC, and maybe see if there are some other
applications I can put it to during the idle times.


I'm still looking for instructions on how the existing FreeBSD
package building clusters are put together. That plus various
bits-n-pieces I've found (mostly from Brooks) should help me figure
out how to try to build my own.

--
Brad Knowles, <***@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

SAGE member since 1995. See <http://www.sage.org/> for more info.
Tillman Hodgson
2004-12-02 15:18:06 UTC
Permalink
On Thu, Dec 02, 2004 at 01:23:57AM +0100, Brad Knowles wrote:
> It's interesting that you mention this. I've been giving some
> thought to how I might be able to dive in and start seriously working
> on building my UltraSPARC cluster (based on the four U10 clones I
> have already, plus as many U5s as I can throw into the mix), and I
> was hoping to find a better solution than NFS, and AFS/Coda/OpenAFS
> was tops of my list of alternatives to consider.

I'll second that. every few months I test OpenAFS on FreeBSD and every
few months I think it's only a few months away from working ;-)

In a Kerberos environment, AFS is a beautiful thing.

> In particular, if I can get this thing working reasonably well,
> I'd like to turn this into a package building cluster for
> FreeBSD/UltraSPARC, and maybe see if there are some other
> applications I can put it to during the idle times.

That would be handy. My U5 isn't all that fast (mostly due to the IDE
crap interface), so building large apps is reasonably annoying. It's one
of the few boxes that I do portupgrades monthly (or less) rather than as
they come out.

-T


--
"Nostalgia is a seductive liar."
-- George W. Ball
Scott Long
2004-12-01 23:37:59 UTC
Permalink
Jason C. Wells wrote:
> --On Wednesday, December 01, 2004 3:02 PM -0700 Scott Long
> <***@freebsd.org> wrote:
>
>> 5. Clustered FS support. SANs are all the rage these days, and
>> clustered filesystems that allow data to be distributed across many
>> storage enpoints and accessed concurrently through the SAN are very
>> powerful. RedHat recently bought Sistina and re-opened the GFS source
>> code, so exploring this would be very interesting.
>
>
> This sounds very close to OpenAFS. I don't know what distinguishes a
> SAN from other types of NAS. OpenAFS does everything you mentioned in
> the above paragraph. OpenAFS _almost_ works on FreeBSD right now.
>
> Later,
> Jason C. Wells

Well, AFS requires an intelligent node in front of each disk. True SAN
clustering means that you have a web of disks directly connected to the
SAN (iSCSI, FibreChannel, etc), and two or more servers on the SAN that
see those disks as a single filesystem (actually a bit more complicated
than this, but you get the point). If one server goes down, no access
to data is lost since the disks can be reached from any other server on
the SAN that is participating in the clustered FS.

Scott
Miguel Mendez
2004-12-02 06:55:30 UTC
Permalink
On Thu, 02 Dec 2004 10:44:32 +0530
"Kamal R. Prasad" <***@acm.org> wrote:

[Please don't top-post]

> I find X windows to be a bit too compute intensive. Maybe something
> like apple's interface would be a good alternative [for those who
> don't need X-windows' powerful graphic features].

What makes you think so? X was originally desgined for systems with
little memory and processing power, certainly a lot less than today's
AMD and Intel space heaters. There are some features that do indeed
require more CPU, like antialiasing. That's the price to pay for eye
candy. Things like the composite and damage extensions do wonders to
help in those areas and make things like true transparency and alpha
blending possible. So, in time, X won't be that different from Aqua in
its use of hardware.

The lack of speed in some apps can be blamed mostly on the toolkits.
GTK+ 1.2 was a speed demon, GTK+ 2.x is a lot slower. There are some
people working on a fast Pango code path that could make english text
rendering fast again.

X gives you network transparency out of the box. I used an old SGI Indy
as an X term to connect to my FreeBSD box for years, and it worked like
a charm over a 10Mbit connection.

Replacing X means writing something that's API compatible, or writing an
X server on top of your new display system, so that you don't have to
throw the thousands of X apps into the trashcan.

About some of the other comments in the thread. IMHO using bsdinstaller
as a base could be beneficial for both groups and save duplicated work.
I'm sure they'll be glad to get internacionalization patches.

I agree that a journaled filesystem is really needed if you want to
manage multi TiB partitions. As rock solid and tested softupdates is,
fsck is not an acceptable solution in this case. Some people were
working on a port of XFS, has any progress been made? I tried contacting
them some time ago, but never got an answer. Sounds like a very
interesting, though.

Cheers,
--
Miguel Mendez <***@energyhq.es.eu.org> | lea gfx_lib(pc),a1
http://www.energyhq.es.eu.org | moveq #0,d0
PGP Key: 0xDC8514F1 | move.l 4.w,a6
Note: All HTML mail goes to /dev/null | jsr -552(a6)
Eric Anholt
2004-12-02 07:50:36 UTC
Permalink
On Wed, 2004-12-01 at 22:55, Miguel Mendez wrote:
> On Thu, 02 Dec 2004 10:44:32 +0530
> "Kamal R. Prasad" <***@acm.org> wrote:
>
> [Please don't top-post]
>
> > I find X windows to be a bit too compute intensive. Maybe something
> > like apple's interface would be a good alternative [for those who
> > don't need X-windows' powerful graphic features].
>
> What makes you think so? X was originally desgined for systems with
> little memory and processing power, certainly a lot less than today's
> AMD and Intel space heaters. There are some features that do indeed
> require more CPU, like antialiasing. That's the price to pay for eye
> candy. Things like the composite and damage extensions do wonders to
> help in those areas and make things like true transparency and alpha
> blending possible. So, in time, X won't be that different from Aqua in
> its use of hardware.
>
> The lack of speed in some apps can be blamed mostly on the toolkits.
> GTK+ 1.2 was a speed demon, GTK+ 2.x is a lot slower. There are some
> people working on a fast Pango code path that could make english text
> rendering fast again.
>
> X gives you network transparency out of the box. I used an old SGI Indy
> as an X term to connect to my FreeBSD box for years, and it worked like
> a charm over a 10Mbit connection.
>
> Replacing X means writing something that's API compatible, or writing an
> X server on top of your new display system, so that you don't have to
> throw the thousands of X apps into the trashcan.

Let me see if I can come up with a sensible response to this, which I've
lost the original message for:

We already have the stuff to do all of the pretty Apple eye-candy in
X.Org 6.8, with the Composite/Damage/Fixes extensions. The same
eye-candy support is a requirement to provide the perception of speed
that you get out of other modern graphical systems, by removing the
latency for redrawing when moving/mapping windows. You can use xcompmgr
-a and compare what that gets you when dragging windows -- it's pretty
decent. The problem we hit is when you try to add eye-candy, such as
xcompmgr -c (drop shadows, fadey menus, etc.), things bog down. These
are exactly the "powerful graphic features" that the combination of
Composite and Render allow, and they're just like the operations Apple
uses for all of their fancy stuff. The problem is that we aren't
hardware-accelerating them currently. I've worked on building a
moderately dumb X Server for ATI cards, and it gives apple-like
performance on even Rage 128s -- it's not terribly complicated, just a
matter of pushing things to hardware and avoiding the ~50x speed penalty
of CPU reading from framebuffer. Now what we need to do is get a
sensible acceleration architecture into X.Org so we can get these
operations in hardware for all of the chipsets that we've got 3d docs or
drivers for (ati, some nvidia, 3dfx, intel, mga, trident, sis, savage,
gamma, and a bunch of others I'm forgetting).

In short: There are no problems with X, except that we need somebody to
bring us a sane acceleration architecture. I'm hoping I can get a job
doing that this summer, as it'll be a significant undertaking that I
can't get to while in my last year of school.

--
Eric Anholt ***@lclark.edu
http://people.freebsd.org/~anholt/ ***@FreeBSD.org
Thank goodness for the 22nd Amendment
Jeremie Le Hen
2004-12-02 08:47:20 UTC
Permalink
> In short: There are no problems with X, except that we need somebody to
> bring us a sane acceleration architecture. I'm hoping I can get a job
> doing that this summer, as it'll be a significant undertaking that I
> can't get to while in my last year of school.

Remember that very recently Microsoft announced on their own website that
DirectX was running on the FreeBSD platform :-).

[ This is a joke, for those who didn't see the famous web page. ]

--
Jeremie Le Hen
***@le-hen.org
Eric Anholt
2004-12-03 08:37:29 UTC
Permalink
On Thu, 2004-12-02 at 17:35, David Xu wrote:
> I maybe jump onto wrong thread, but FreeBSD's lack of
> graphics framebuffer which is in Linux really kicked away
> lots of embedded projects, one is QT-embedded which
> simple can not be run on FreeBSD, many embedded projects
> here just need it.

We do definitely need framebuffer. But I think we'd be best served by
trying to drag mode-setting code out of the X Server and into a userland
library, rather than integrating it all into the kernel. (At most,
implement a simple fixed mode supported everywhere in the kernel for
intial boot, then a userland system of some sort takes over after
that). Mode-setting code is huge, easy to mess up, and I don't think we
have the resources to do it well. However, if someone (I fear doing
this myself) were to get it into a userland library, we could probably
convince the X Server to use it, and maybe even Linux kernel folks, and
end up keeping all grahpics driver developers focused on a single
codebase rather than split across many OSes or kernel versus X Server.

Here's why I personally think this is really important: We've got
Mesa-solo laying around -- OpenGL hardware acceleration on top of a
framebuffer, if FreeBSD just had a framebuffer system. Then we've got
the Xglx server, which runs on top of an OpenGL implementation and
provides at least some of the Render acceleration that I was talking
about in the parent message. Also, a number of X Server folks want to
get mode-setting moved out of the X Server entirely -- let it be
configured by system daemons, probably controlled over dbus. It would
be very nice if FreeBSD happened to be ready for what Linux people would
like to do.

--
Eric Anholt ***@lclark.edu
http://people.freebsd.org/~anholt/ ***@FreeBSD.org
Thank goodness for the 22nd Amendment
Kamal R. Prasad
2004-12-02 05:14:32 UTC
Permalink
I find X windows to be a bit too compute intensive. Maybe something like
apple's interface would be a good alternative [for those who don't need
X-windows' powerful graphic features].

regards
-kamal

Scott Long wrote:

> Jason C. Wells wrote:
>
>> --On Wednesday, December 01, 2004 3:02 PM -0700 Scott Long
>> <***@freebsd.org> wrote:
>>
>>> 5. Clustered FS support. SANs are all the rage these days, and
>>> clustered filesystems that allow data to be distributed across many
>>> storage enpoints and accessed concurrently through the SAN are very
>>> powerful. RedHat recently bought Sistina and re-opened the GFS source
>>> code, so exploring this would be very interesting.
>>
>>
>>
>> This sounds very close to OpenAFS. I don't know what distinguishes a
>> SAN from other types of NAS. OpenAFS does everything you mentioned
>> in the above paragraph. OpenAFS _almost_ works on FreeBSD right now.
>>
>> Later,
>> Jason C. Wells
>
>
> Well, AFS requires an intelligent node in front of each disk. True SAN
> clustering means that you have a web of disks directly connected to the
> SAN (iSCSI, FibreChannel, etc), and two or more servers on the SAN that
> see those disks as a single filesystem (actually a bit more complicated
> than this, but you get the point). If one server goes down, no access
> to data is lost since the disks can be reached from any other server on
> the SAN that is participating in the clustered FS.
>
> Scott
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-***@freebsd.org"
Peter Jeremy
2004-12-02 19:03:38 UTC
Permalink
On Thu, 2004-Dec-02 07:55:30 +0100, Miguel Mendez wrote:
>On Thu, 02 Dec 2004 10:44:32 +0530
>"Kamal R. Prasad" <***@acm.org> wrote:
>> I find X windows to be a bit too compute intensive. Maybe something
>> like apple's interface would be a good alternative [for those who
>> don't need X-windows' powerful graphic features].
>
>What makes you think so? X was originally desgined for systems with
>little memory and processing power, certainly a lot less than today's
>AMD and Intel space heaters.

Agreed. But I don't think performance is the issue with X. As I see
it, there are several major problems with building an X installer:
1) It quite common in the server arena for machines not to have any
graphics head and X is incompatible with serial terminals.
2) You need to configure the X server to support your video adapter,
mouse, keyboard and screen. Remember, the "standard" basic VGA
interface doesn't necessarily exist outside the PC world. There
are enough problems with keyboards (see one of Scott's other wishes)
without wanting to add mice, screens and video adapters.
3) /stand is ~2.7M on i386. A minimal X environment is going to be
50-70MB. This means 50-70MB less packages on CD1.
4) X is a RAM hog by sysinstall standards. The minimum RAM requirements
will go up significantly. Whilst this shouldn't worry current
generation hardware, it will make installing FreeBSD on older hardware
(486 and P1) very difficult.

Yes, X is network aware but this doesn't really help for system
installation. You might solve points 1 and 2 but you replace them
with the issue of how to bring up the network and arrange appropriate
client/server communication and authentication.

--
Peter Jeremy
Eric Kjeldergaard
2004-12-02 19:19:12 UTC
Permalink
> Agreed. But I don't think performance is the issue with X. As I see
> it, there are several major problems with building an X installer:
> 1) It quite common in the server arena for machines not to have any
> graphics head and X is incompatible with serial terminals.
> 2) You need to configure the X server to support your video adapter,
> mouse, keyboard and screen. Remember, the "standard" basic VGA
> interface doesn't necessarily exist outside the PC world. There
> are enough problems with keyboards (see one of Scott's other wishes)
> without wanting to add mice, screens and video adapters.
> 3) /stand is ~2.7M on i386. A minimal X environment is going to be
> 50-70MB. This means 50-70MB less packages on CD1.
> 4) X is a RAM hog by sysinstall standards. The minimum RAM requirements
> will go up significantly. Whilst this shouldn't worry current
> generation hardware, it will make installing FreeBSD on older hardware
> (486 and P1) very difficult.

I want to preface by saying that I certainly don't think a GUI
installer should replace what FreeBSD ships with now. Having said
that: It has been suggested in the past, and may as well be suggested
again now, that a liveCD installer be created. I know that amongst
desktop/first-time users this would be a welcome addition. I also
realise that it isn't FreeBSD's main market (though it is a major
consideration). This sort of project could be done with somewhat less
knowledge (I think) than sysinstall itself, and would have many
classes of systems that simply by nature of being a liveCD it wouldn't
have to worry about (I think of headless servers and 486s). Just
thought I would toss the idea out to see what people thought of it at
this point (as I've not heard much about it for a while, and it seems
that many of them were getting ready for 5-STABLE).
--
If I write a signature, my emails will appear more personalised.
Mike Edenfield
2004-12-02 19:34:42 UTC
Permalink
Eric Kjeldergaard wrote:
>>Agreed. But I don't think performance is the issue with X. As I see
>>it, there are several major problems with building an X installer:
>>1) It quite common in the server arena for machines not to have any
>> graphics head and X is incompatible with serial terminals.
>>2) You need to configure the X server to support your video adapter,
>> mouse, keyboard and screen. Remember, the "standard" basic VGA
>> interface doesn't necessarily exist outside the PC world. There
>> are enough problems with keyboards (see one of Scott's other wishes)
>> without wanting to add mice, screens and video adapters.
>>3) /stand is ~2.7M on i386. A minimal X environment is going to be
>> 50-70MB. This means 50-70MB less packages on CD1.
>>4) X is a RAM hog by sysinstall standards. The minimum RAM requirements
>> will go up significantly. Whilst this shouldn't worry current
>> generation hardware, it will make installing FreeBSD on older hardware
>> (486 and P1) very difficult.
>
>
> I want to preface by saying that I certainly don't think a GUI
> installer should replace what FreeBSD ships with now. Having said
> that: It has been suggested in the past, and may as well be suggested
> again now, that a liveCD installer be created. I know that amongst
> desktop/first-time users this would be a welcome addition. I also
> realise that it isn't FreeBSD's main market (though it is a major
> consideration). This sort of project could be done with somewhat less
> knowledge (I think) than sysinstall itself, and would have many
> classes of systems that simply by nature of being a liveCD it wouldn't
> have to worry about (I think of headless servers and 486s). Just
> thought I would toss the idea out to see what people thought of it at
> this point (as I've not heard much about it for a while, and it seems
> that many of them were getting ready for 5-STABLE).

I've spent the past two weeks installing every open-source OS I could
get my hands on into VPC2004 and VMWare virtual machines. There are a
few out there which do provide graphical, or pseudo-graphical,
installations.

Solaris had an X-based install but I suspect Solaris has a much narrower
range of hardware it needs to support.

Plan9 managed to do some very lightweight installation (that fit on a
*floppy*) and was still graphical. I liked their install very much --
it was no-frills console windows, but it provided mouse support and a
couple of "informative" extra windows. But this brings up exactly the
problem with GUI installers -- the plan9 install didn't support the
"graphics adapter" that Virtual PC emulates, and so it just didn't work.
For a nice OS like plan9, this isn't a big deal. For an OS like
FreeBSD I don't think that would be acceptable.

Overall, I installed 10 different OS's, and FreeBSD was probably my
second favorite (I did like DFly, as mentioned before). It's
straightforward, it guides you through the process fairly well, it does
most of the grunt work, it's flexible, it loads and responds fast, and
it's got a lot of on-screen assistance. I picked it up and used it,
with no documentation, the very first time I installed FBSD anywhere.
(Contract to Gentoo, a geek-favorite, which I had to keep their
installation handbook open in a browser the entire time). My only real
complaint (not minior nit-picks like about the auto-labelling etc) is
that it's too easy to move around inside the installation and go the
wrong place. I routinely find myself trying to change a simple setting
post-install, and somehow triggering the entire extraction process
again. DFly's installer is more wizard-like, in that you can't really
do things out of order. Otherwise, I would like to see the install stay
similar to what it is.

--Mike
Jon Drews
2004-12-02 19:55:01 UTC
Permalink
On Thu, 2 Dec 2004 19:19:12 +0000, Eric Kjeldergaard <***@gmail.com> wrote:
> I want to preface by saying that I certainly don't think a GUI
> installer should replace what FreeBSD ships with now.

I agree with Eric. As a FreeBSD desktop user, I think (IMHO) that a
gui installer is a high cost low yield item. It would take a lot of
effort to make it work right. My experience with both YaST and
Mandrakes installer was that it took several releases for the bugs to
get worked out. IIRC SuSE introduced the GUI YaST2 in 7.0 and I think
it was working pretty well by 8.0 but that was over the period of a
year.
Devon H. O'Dell
2004-12-02 20:06:09 UTC
Permalink
Jon Drews wrote:
> On Thu, 2 Dec 2004 19:19:12 +0000, Eric Kjeldergaard <***@gmail.com> wrote:
>
>>I want to preface by saying that I certainly don't think a GUI
>>installer should replace what FreeBSD ships with now.
>
>
> I agree with Eric. As a FreeBSD desktop user, I think (IMHO) that a
> gui installer is a high cost low yield item. It would take a lot of
> effort to make it work right. My experience with both YaST and
> Mandrakes installer was that it took several releases for the bugs to
> get worked out. IIRC SuSE introduced the GUI YaST2 in 7.0 and I think
> it was working pretty well by 8.0 but that was over the period of a
> year.

A couple of the features of our installer are that it is scriptable and
that all of the handling of the installation is done in the back end.
This means that the only bugs which would exist in a GUI front end
(assuming the backend works, as it does) to the installer would be
problems with the widget library or with how it is used.

It'd be pretty simple to extend the installer to use pretty much any
graphical toolkit. Its client/server design, in that sense, makes it
very suitable for any purpose.

FWIW, I saw on another response to this thread that the installer should
be based on a Live CD. Ours is, and is used in the FreeSBIE project to
install FreeBSD to the disk, if desired.

Kind regards,

Devon H. O'Dell
Eric Kjeldergaard
2004-12-02 20:52:36 UTC
Permalink
> FWIW, I saw on another response to this thread that the installer should
> be based on a Live CD. Ours is, and is used in the FreeSBIE project to
> install FreeBSD to the disk, if desired.

Ooh, ooh, do tell. </giddy> I had no idea that one existed. Does it
allow for simple base installs? In fact, does it have about the same
featureset as sysinstall? Do I get a link? Please self-promote :)
I'm sure I'm not alone in the desire for a GUI installer as an option
(not a replacement, again...need to reiterate that I love the ability
to install fBSD in 8 minutes on a 200mhz machine via a familiar
ncurses interface) for desktop users.



--
If I write a signature, my emails will appear more personalised.


--
If I write a signature, my emails will appear more personalised.
Devon H. O'Dell
2004-12-03 07:08:21 UTC
Permalink
Eric Kjeldergaard wrote:
>>FWIW, I saw on another response to this thread that the installer should
>>be based on a Live CD. Ours is, and is used in the FreeSBIE project to
>>install FreeBSD to the disk, if desired.
>
>
> Ooh, ooh, do tell. </giddy> I had no idea that one existed. Does it
> allow for simple base installs? In fact, does it have about the same
> featureset as sysinstall? Do I get a link? Please self-promote :)
> I'm sure I'm not alone in the desire for a GUI installer as an option
> (not a replacement, again...need to reiterate that I love the ability
> to install fBSD in 8 minutes on a 200mhz machine via a familiar
> ncurses interface) for desktop users.
>
>
>
> --
> If I write a signature, my emails will appear more personalised.

I believe it's to be shipped with the FreeSBIE 1.1 release. It used to
be on www.livebsd.com, but I think Scott (Ullrich) removed it (or I may
be wrong). You can obviously check out its functionality for DragonFly
BSD (the interface when installing FreeSBIE is the same).

The FreeSBIE project is at http://www.freesbie.org

Have fun! :)

Devon H. O'Dell
Massimiliano Stucchi
2004-12-03 17:02:17 UTC
Permalink
On 031204, 08:08, Devon H. O'Dell wrote:
>
> I believe it's to be shipped with the FreeSBIE 1.1 release. It used to
> be on www.livebsd.com, but I think Scott (Ullrich) removed it (or I may
> be wrong). You can obviously check out its functionality for DragonFly
> BSD (the interface when installing FreeSBIE is the same).

Yup, it will be shipped with FreeSBIE-1.1, which is due in a couple
days, one we work out final settings.

Get ready for it

Ciao !
--

Massimiliano Stucchi
WillyStudios.com
***@willystudios.com
Http://www.willystudios.com/max/
Sam
2004-12-02 21:08:41 UTC
Permalink
> I want to preface by saying that I certainly don't think a GUI
> installer should replace what FreeBSD ships with now. Having said
> that: It has been suggested in the past, and may as well be suggested
> again now, that a liveCD installer be created. I know that amongst
> desktop/first-time users this would be a welcome addition. I also
> realise that it isn't FreeBSD's main market (though it is a major
> consideration). This sort of project could be done with somewhat less
> knowledge (I think) than sysinstall itself, and would have many
> classes of systems that simply by nature of being a liveCD it wouldn't
> have to worry about (I think of headless servers and 486s). Just
> thought I would toss the idea out to see what people thought of it at
> this point (as I've not heard much about it for a while, and it seems
> that many of them were getting ready for 5-STABLE).

I like the idea of having a separate boot-CD for those wishing to
get a fancy GUI installer -- just so long as you can still boot
from CD1 and get a text-based version, no matter how rudimentary.
Wilko Bulte
2004-12-02 19:12:57 UTC
Permalink
On Wed, Dec 01, 2004 at 04:37:59PM -0700, Scott Long wrote..
> Jason C. Wells wrote:
> >--On Wednesday, December 01, 2004 3:02 PM -0700 Scott Long
> ><***@freebsd.org> wrote:
> >
> >>5. Clustered FS support. SANs are all the rage these days, and
> >>clustered filesystems that allow data to be distributed across many
> >>storage enpoints and accessed concurrently through the SAN are very
> >>powerful. RedHat recently bought Sistina and re-opened the GFS source
> >>code, so exploring this would be very interesting.
> >
> >
> >This sounds very close to OpenAFS. I don't know what distinguishes a
> >SAN from other types of NAS. OpenAFS does everything you mentioned in
> >the above paragraph. OpenAFS _almost_ works on FreeBSD right now.
> >
> >Later,
> >Jason C. Wells
>
> Well, AFS requires an intelligent node in front of each disk. True SAN
> clustering means that you have a web of disks directly connected to the
> SAN (iSCSI, FibreChannel, etc), and two or more servers on the SAN that
> see those disks as a single filesystem (actually a bit more complicated
> than this, but you get the point). If one server goes down, no access
> to data is lost since the disks can be reached from any other server on
> the SAN that is participating in the clustered FS.

Find a friendly TruCluster somewhere and take a look. Really Neat(tm).
Alternatively find a friendly OpenVMS cluster, they have forgotten more
about clusters now than Unix will ever learn (I am afraid).

While we are talking storage: multipathing support for SANs is a
very neat thing to have. Devices uniquely identified by WWN etc.

--
Wilko Bulte ***@FreeBSD.org
Dan Nelson
2004-12-01 23:47:36 UTC
Permalink
In the last episode (Dec 01), Jason C. Wells said:
> --On Wednesday, December 01, 2004 3:02 PM -0700 Scott Long
> <***@freebsd.org> wrote:
>
> >5. Clustered FS support. SANs are all the rage these days, and
> >clustered filesystems that allow data to be distributed across many
> >storage enpoints and accessed concurrently through the SAN are very
> >powerful. RedHat recently bought Sistina and re-opened the GFS source
> >code, so exploring this would be very interesting.
>
> This sounds very close to OpenAFS. I don't know what distinguishes a
> SAN from other types of NAS. OpenAFS does everything you mentioned
> in the above paragraph. OpenAFS _almost_ works on FreeBSD right now.

OpenAFS is a network-centric system that replicates data across its
nodes, I think, and each node has a cache. A clustered filesystem uses
a single block of shared storage (usually on a fibre-channel SAN, but
you can also use shared scsi on a 2-machine cluster) that all servers
access directly. The magic is getting the locking right to make sure
the servers don't stomp on each other's data. Extremely useful for
server farms that need to share large files, or even lots of small
files (webservers for example).

--
Dan Nelson
***@allantgroup.com
Marcel Moolenaar
2004-12-02 00:29:39 UTC
Permalink
On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote:
>
> 1. Keyboard multiplexer.

I actually fail to stop thinking about a complete syscons and pcvt
replacement. You know, the one and only console implementation that
makes all others obsolete. Big plans, little time, yada yada yada...

> 2. New installer.

It may actually be interesting to see if we can make an expert
system for this. When I think about implementing an installer (alas
I've been doing that), I'm not so much interested in how things are
packaged, or how it looks but rather what needs to be done, when and
how all these actions relate and interact with each other. This is
especially tricky when actions are triggered by the current
configuration of the machine onto which one tries to install. Knowing
all the possible activities and their dependencies should help
establish a control flow through the installation process in such a
way that users get asked only those questions that are relevent and
also when it matters. One puts a UI on top of this to get a nice
looking installer. At least, that's how I look at it...

--
Marcel Moolenaar USPA: A-39004 ***@xcllnt.net
Scott Long
2004-12-02 00:40:00 UTC
Permalink
Marcel Moolenaar wrote:
> On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote:
>
>>1. Keyboard multiplexer.
>
>
> I actually fail to stop thinking about a complete syscons and pcvt
> replacement. You know, the one and only console implementation that
> makes all others obsolete. Big plans, little time, yada yada yada...
>
>
>>2. New installer.
>
>
> It may actually be interesting to see if we can make an expert
> system for this. When I think about implementing an installer (alas
> I've been doing that), I'm not so much interested in how things are
> packaged, or how it looks but rather what needs to be done, when and
> how all these actions relate and interact with each other. This is
> especially tricky when actions are triggered by the current
> configuration of the machine onto which one tries to install. Knowing
> all the possible activities and their dependencies should help
> establish a control flow through the installation process in such a
> way that users get asked only those questions that are relevent and
> also when it matters. One puts a UI on top of this to get a nice
> looking installer. At least, that's how I look at it...
>

Yeah, I've had many similar thoughts. The hard part of a new installer,
or any complex UI application, is the framework that ties events and
actions together. The easy part is writing the modules on top of that
that do the discrete actions. While I see quite a few rough edges in
the upper layers of the DF installer, it seems like quite a bit of work
is going into the framework, and that's why I'm actually so interested
in it.

Scott
Foxfair Hu
2004-12-02 01:17:58 UTC
Permalink
On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote:
> All,
>
[....]
>
> 1. Keyboard multiplexer. We are running into problems with making
> ps/2 and USB/bluetooth keyboards work together and work with KVMs.
> Having a virtual keyboard device that multiplexes the various real
> keyboard devices and handles hotplug can solve this mess pretty
> effectively. I know that there has been a lot of talk about this on
> mailing lists recently but I don't know how much progress is being made
> so I'm listing it here.

How about reuse NetBSD's wscons ? I've kept an eye on it and thought
it should be a good start for FreeBSD.


foxfair
Scott Long
2004-12-02 01:41:52 UTC
Permalink
Foxfair Hu wrote:
> On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote:
>
>>All,
>>
>
> [....]
>
>>1. Keyboard multiplexer. We are running into problems with making
>>ps/2 and USB/bluetooth keyboards work together and work with KVMs.
>>Having a virtual keyboard device that multiplexes the various real
>>keyboard devices and handles hotplug can solve this mess pretty
>>effectively. I know that there has been a lot of talk about this on
>>mailing lists recently but I don't know how much progress is being made
>>so I'm listing it here.
>
>
> How about reuse NetBSD's wscons ? I've kept an eye on it and thought
> it should be a good start for FreeBSD.
>
>
> foxfair
>

If it provides keyboard mux'ing like we need, then please go and
give it a shot.

Scott
M. Warner Losh
2004-12-02 03:53:22 UTC
Permalink
In message: <***@freebsd.org>
Scott Long <***@freebsd.org> writes:
: 1. Keyboard multiplexer. We are running into problems with making
: ps/2 and USB/bluetooth keyboards work together and work with KVMs.
: Having a virtual keyboard device that multiplexes the various real
: keyboard devices and handles hotplug can solve this mess pretty
: effectively. I know that there has been a lot of talk about this on
: mailing lists recently but I don't know how much progress is being made
: so I'm listing it here.

There aready are multiplexers in the kernel. The problem is that we
need a many to one mux that is the OR of all the ones installed. We
can current set WHICH keyboard is connected to the mux, but can't say
'ALL OF THEM' at all. I believe that Brooks Davis has said he's
working on this.

Warner
Alex Povolotsky
2004-12-02 05:13:52 UTC
Permalink
On Wed, 01 Dec 2004 15:02:40 -0700
Scott Long <***@freebsd.org> wrote:

SL> 4. Journaled filesystem. While we can debate the merits of speed

SL>
SL> 5. Clustered FS support. SANs are all the rage these days, and

Maybe you could also look at unionFS?

unionfs -b could be extremly useful for multiple jails...

--
Alex.
John Hay
2004-12-02 05:54:54 UTC
Permalink
> >
> > 1. Keyboard multiplexer.
>
> I actually fail to stop thinking about a complete syscons and pcvt
> replacement. You know, the one and only console implementation that
> makes all others obsolete. Big plans, little time, yada yada yada...

It would be nice if one would still be able to use the keyboards
separately too, even if you have to recompile the kernel for that.
One nice usage would be on HP's quad kiosk machine. It is a single
processor box with 4 x screen, keyboard and mouse, and then 4 people
can use it.

John
--
John Hay -- ***@icomtek.csir.co.za / ***@FreeBSD.org
M. Warner Losh
2004-12-02 06:33:45 UTC
Permalink
In message: <***@zibbi.icomtek.csir.co.za>
John Hay <***@icomtek.csir.co.za> writes:
: > > 1. Keyboard multiplexer.
: >
: > I actually fail to stop thinking about a complete syscons and pcvt
: > replacement. You know, the one and only console implementation that
: > makes all others obsolete. Big plans, little time, yada yada yada...
:
: It would be nice if one would still be able to use the keyboards
: separately too, even if you have to recompile the kernel for that.
: One nice usage would be on HP's quad kiosk machine. It is a single
: processor box with 4 x screen, keyboard and mouse, and then 4 people
: can use it.

I think that making it just another driver that knows about the
keyboard mux would make this possible in the short term...

Hmmm, maybe it is time for me to STFU and hack together what I'm
thinking :-)

Warner
Devon H. O'Dell
2004-12-02 08:01:09 UTC
Permalink
Ryan Sommers wrote:
> Scott Long said:
>
>>2. New installer. I know some people still consider this a joke, but
>>the reality is that sysinstall is no longer state of the art. It's
>>fairly good at the simple task that it does, but it's becoming harder
>>and harder to fix bugs and extend functionality in it. It's also
>>fairly unfriendly to those of us who haven't been using it since 1995.
>>The DFly folks have some very interesting work in this area
>>(www.bsdinstaller.com) and it would be very good to see if we can
>>collaborate with them on it.
>
>
> I've spent a good deal of time taking notes and diagrams of what I wanted
> from a new installer. However, time constraints have kept me from actually
> putting any of it to code yet.
>
> I've looked at the DFly installed quite a bit and I like what it offers,
> however, I have a few complaints with it. Quite honestly I wasn't
> impressed with the code.
>
> Another issue I had with the dfly installer was one point I believe needs
> to be central to any next-gen installer. Internationalisation. My idea of
> an installer front-end would use a dynamically loadable language library.
> All resources of the front-end (ie strings, images, etc) would be packaged
> into a seperate language-pack. These language-packs can then be grouped
> together into a language library. A few basic packs would be distributed
> with the default library but other libraries could easily be substituted
> to make localized distribution sets with little trouble.
>
> The benefit of this is that instead of translating the code you would only
> need to translate the language-(pack|library). I think this would greatly
> simplify translation and make a seperation between language and the
> front-end code.
>
> This is where my complaint with Dfly comes in, upon reading the source,
> there are string constants everywhere. Perhaps I am missing something, but
> this means that in order to supply localization support much work would
> need to be done to find some scheme that doesn't mean translating the
> source.
>
> I have quite a bit of notes on seperation and even down to specific
> methods and sub-libraries necessary for the back-end. Perhaps if I have
> some time soon I'll put it into a PDF somewhere.
>
> Has anyone else put much thought into this?

Yes, we have. I18n is something that we're actively working on
implementing, and is something that we take quite seriously. I know that
not very many FreeBSD developers use IRC, but we are all available in
#dfinstaller on EFNet. We're using gettext for this at the moment.

Kind regards,

Devon H. O'Dell
Eric Masson
2004-12-02 08:59:47 UTC
Permalink
>>>>> "Scott" == Scott Long <***@freebsd.org> writes:

Hi,

Scott> 1. Keyboard multiplexer. We are running into problems with
Scott> making ps/2 and USB/bluetooth keyboards work together and work
Scott> with KVMs. Having a virtual keyboard device that multiplexes the
Scott> various real keyboard devices and handles hotplug can solve this
Scott> mess pretty effectively. I know that there has been a lot of
Scott> talk about this on mailing lists recently but I don't know how
Scott> much progress is being made so I'm listing it here.

NetBSD's wscons seems to fit in this scheme, OpenBSD has adopted it as
well (the most featured implementation is in NetBSD/i386).

Scott> 6. Overhaul CAM, add iSCSI. CAM is very parallel-SCSI centric
Scott> right now. I have some work-in-progress in Perforce to address
Scott> this, but it's pretty minimal. The parallel SCSI knowledge needs
Scott> to be separated out and the stack need to be able to cleanly
Scott> deal with iSCSI, SCSI, SAS, and maybe even ATA transports. There
Scott> is a Lucent implementation of iSCSI for FreeBSD 4.x that could
Scott> be a useful reference, though it's a monolithic stack that
Scott> doesn't really address the shortcomings of CAM. Having iSCSI
Scott> infrastructure that supported both hardware and software
Scott> implementations would be ideal.

It would be really nice to be able to play in the iscsi field. It seems
that work has been done in this area by Wasabi (not published in NetBSD,
iirc)

Very appealing goals, if only I were a decent coder...

Éric Masson

--
je pense pas que ce soit toi....tu es bien trop vicieux pour agir de
cette façon. Toi ton genre, c'est plus de contacter banque direct en
esperant que je n'auras pas mes cadeaux de parrainages!!!!!
-+- JD in <http://www.le-gnu.net> : Petit neuneu Noël -+-
Poul-Henning Kamp
2004-12-02 10:33:40 UTC
Permalink
In message <***@freebsd.org>, Scott Long writes:
>All,
>
>I know that I said last month that we were going to stop promising
>specific features for the next major release. However, I'd like to
>throw out a list of things that would be really nice to have in the
>future, whether its 6.0 or 7.0 or whatever.
>[...]
>1. Keyboard multiplexer. [...]
>2. New installer. [...]
>3. Native PCI Express support. [...]
>4. Journaled filesystem. [...]
>5. Clustered FS support. [...]
>6. Overhaul CAM, add iSCSI. [...]

I agree on all of the above but I think we also need to have things
on the list that doesn't take super hackers, and architectural
reviews.

So let us add the following points which I think are just as, if
not more important for FreeBSDs future:

7. More people writing FreeBSD related articles for online and
traditional media.

If you have never written a piece about FreeBSD, how about sending
something to your local IT trade rag ? Heck, even your local
paper will probably run it if you send them a piece.


8. More people stomping for FreeBSD in universities and schools.

Have you actually offered the science/IT teachers at the local
hi-school to pop around and give a lesson on this open source
phenomena to their pupils ?

Or call your local college and ask if they need a teaching
assistant for their evening courses in IT ?


9. A band of happy 1st line reponders dealing with PRs etc.

We're getting better at this, but one way to really gain users
is to help them when they need it most: right when they begin.


10. A more dynamic and interesting www.freebsd.org frontpage.

Come on, at least we should be able to beat the "Congressional
Record" when it comes to being interesting.


11. More people attending BSDcon conferences.

Come to BSDcan2005! come to the next EuroBSDcon or AsiaBSDcon.

Or make your own mini conference!

Many Linux User groups would welcome you if you offered to give
a talk about FreeBSD on one of their evenings.


12. Research/Coding grants (3/6/12 months) from the FreeBSD Foundation
and other deep(er) pockets to help some of the heavy lifting happen.

We're not only in it for the money, but money surely helps.


And I'd like to stress that none of the above requires you to get
permission from the core team, just go out and do it!

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Mark Linimon
2004-12-02 00:11:30 UTC
Permalink
On Wed, 1 Dec 2004, Scott Long wrote:

> 2. New installer. [... sysinstall] is fairly good at the simple
> task that it does [ ... ]

I'll put my bugmeister-hat on and simply say that query-pr suggests
otherwise. I have not spent sufficient time examining each of the
PRs to figure out what the breakdown is between 'bugs within sysinstall'/
'unable to boot FreeBSD on hardware'/'user error' but IMHO the first
group contains more than a handful of PRs. (the total # is 142.)

This is not to say we should abandon the KISS principle and try to
come up with some all-singing/all-dancing "thing"; in fact, the
opposite. I'd rather we spent time on making something small and
solid which would contain enough of its own documentation to prevent
people from tearing their hair out while trying to use it. Unlike
much of the rest of the system where we assume users have at least
some familiarity with FreeBSD (and a working browser), we have to
engineer an installer that assumes that both of those are false.

Unfortunately for me I probably will never be able to work on this
unless someone wants to pay me to work on FreeBSD full-time; too
many other things are ahead of it in my personal FreeBSD queue ...

mcl
Danny Braniss
2004-12-02 13:50:00 UTC
Permalink
> As far as the iSCSI stuff, I have the Lucent stuff and am trying to use it
> as a reference to build an iSCSI target. I have been experimenting a bit.
>
> The design goal is to have the negotiation stuff running in a user daemon,
> while the target data handling is completely in the kernel. I was thinking
> about using netgraph for the network side of things. On the "disk" side of
> things I am thinking about a geom provider, but not initially. Initially I
> will send the SCSI CDBs directly to a tape drive that is used for testing
> purposes. The project I need this for is to offer a FreeBSD connected tape
> library to a Windoze box with iSCSI and use native NTBACKUP.
>
> Later on the FreeBSD target will be geom based.
>
> Peter

I would like to help/cooperate, I have a netapp with iSCSI awarness, and if
necessary i can get a SAN/iSCSI, and probably some time too.

danny
Peter Blok
2004-12-02 13:25:13 UTC
Permalink
As far as the iSCSI stuff, I have the Lucent stuff and am trying to use it
as a reference to build an iSCSI target. I have been experimenting a bit.

The design goal is to have the negotiation stuff running in a user daemon,
while the target data handling is completely in the kernel. I was thinking
about using netgraph for the network side of things. On the "disk" side of
things I am thinking about a geom provider, but not initially. Initially I
will send the SCSI CDBs directly to a tape drive that is used for testing
purposes. The project I need this for is to offer a FreeBSD connected tape
library to a Windoze box with iSCSI and use native NTBACKUP.

Later on the FreeBSD target will be geom based.

Peter

-----Original Message-----
From: owner-freebsd-***@freebsd.org
[mailto:owner-freebsd-***@freebsd.org] On Behalf Of Scott Long
Sent: Wednesday, December 01, 2004 11:03 PM
To: ***@freebsd.org
Cc: ***@freebsd.org
Subject: My project wish-list for the next 12 months

All,

I know that I said last month that we were going to stop promising
specific features for the next major release. However, I'd like to
throw out a list of things that would be really nice to have in the
future, whether its 6.0 or 7.0 or whatever. Most of these tasks are
not trivial, but I hope that talking about them will encourage some
interest. These are in no particular priority order. I'd also be
thrilled if someone wanted to dress this list up in docbook and add
it to the webpage. While this is just my personal list, I'd welcome
other additions to it (in the sense of significant projects, not just
individual PRs or bug fixes that one might be interested in).

1. Keyboard multiplexer. We are running into problems with making
ps/2 and USB/bluetooth keyboards work together and work with KVMs.
Having a virtual keyboard device that multiplexes the various real
keyboard devices and handles hotplug can solve this mess pretty
effectively. I know that there has been a lot of talk about this on
mailing lists recently but I don't know how much progress is being made
so I'm listing it here.

2. New installer. I know some people still consider this a joke, but
the reality is that sysinstall is no longer state of the art. It's
fairly good at the simple task that it does, but it's becoming harder
and harder to fix bugs and extend functionality in it. It's also
fairly unfriendly to those of us who haven't been using it since 1995.
The DFly folks have some very interesting work in this area
(www.bsdinstaller.com) and it would be very good to see if we can
collaborate with them on it.

3. Native PCI Express support. I keep on hoping to take care of this,
but I never seem to have the time to get past designing it. This task
includes 3 parts that are mostly independent. The first is support for
the extended PCI config space and memio access method, the second is
MSI, and the third is link QOS management. If anyone is interested
here, please let me know.

4. Journaled filesystem. While we can debate the merits of speed and
data integrety of journalling vs. softupdates, the simple fact remains
that softupdates still requires a fsck run on recovery, and the
multi-terabyte filesystems that are possible these days make fsck a very
long and unpleasant experience, even with bg-fsck. There was work at
some point at RPI to add journaling to UFS, but there hasn't been much
status on that in a long time. There have also been proposals and
works-in-progress to port JFS, ReiserFS, and XFS. Some of these efforts
are still alive, but they need to be seen through to completion. But at
the risk of opening a can of worms here, I'll say that it's also
important to explore non-GPL alternatives.

5. Clustered FS support. SANs are all the rage these days, and
clustered filesystems that allow data to be distributed across many
storage enpoints and accessed concurrently through the SAN are very
powerful. RedHat recently bought Sistina and re-opened the GFS source
code, so exploring this would be very interesting.

6. Overhaul CAM, add iSCSI. CAM is very parallel-SCSI centric right
now. I have some work-in-progress in Perforce to address this, but it's
pretty minimal. The parallel SCSI knowledge needs to be separated out
and the stack need to be able to cleanly deal with iSCSI, SCSI, SAS, and
maybe even ATA transports. There is a Lucent implementation of iSCSI
for FreeBSD 4.x that could be a useful reference, though it's a
monolithic stack that doesn't really address the shortcomings of CAM.
Having iSCSI infrastructure that supported both hardware and software
implementations would be ideal.

_______________________________________________
freebsd-***@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-***@freebsd.org"
Andre Oppermann
2004-12-02 14:41:48 UTC
Permalink
Scott Long wrote:
> 5. Clustered FS support. SANs are all the rage these days, and
> clustered filesystems that allow data to be distributed across many
> storage enpoints and accessed concurrently through the SAN are very
> powerful. RedHat recently bought Sistina and re-opened the GFS source
> code, so exploring this would be very interesting.

There are certain steps that can be be taken one at a time. For example
it should be relatively easy to mount snapshots (ro) from more than one
machine. Next step would be to mount a full 'rw' filesystem as 'ro' on
other boxes. This would require cache and sector invalidation broadcasting
from the 'rw' box to the 'ro' mounts. The holy grail of course is to mount
the same filesystem 'rw' on more than one box, preferrably more than two.
This requires some more involved synchronization and locking on top of the
cache invalidation. And make sure that the multi-'rw' cluster stays alive
if one of the participants freezes and doesn't respond anymore.

Scrolling through the UFS/FFS code I think the first one is 2-3 days of
work. The second 2-4 weeks and the third 2-3 month to get it right.
If someone would throw up the money...

--
Andre
Sam
2004-12-02 17:30:12 UTC
Permalink
On Thu, 2 Dec 2004, Andre Oppermann wrote:

> Scott Long wrote:
>> 5. Clustered FS support. SANs are all the rage these days, and
>> clustered filesystems that allow data to be distributed across many
>> storage enpoints and accessed concurrently through the SAN are very
>> powerful. RedHat recently bought Sistina and re-opened the GFS source
>> code, so exploring this would be very interesting.
>
> There are certain steps that can be be taken one at a time. For example
> it should be relatively easy to mount snapshots (ro) from more than one
> machine. Next step would be to mount a full 'rw' filesystem as 'ro' on
> other boxes. This would require cache and sector invalidation broadcasting
> from the 'rw' box to the 'ro' mounts. The holy grail of course is to mount
> the same filesystem 'rw' on more than one box, preferrably more than two.
> This requires some more involved synchronization and locking on top of the
> cache invalidation. And make sure that the multi-'rw' cluster stays alive
> if one of the participants freezes and doesn't respond anymore.
>
> Scrolling through the UFS/FFS code I think the first one is 2-3 days of
> work. The second 2-4 weeks and the third 2-3 month to get it right.
> If someone would throw up the money...

You might also design in consideration for data redundancy. Right now
GFS largely relies on the SAN box to export already redundant RAID
disks. GFS sits on a "cluster aware" lvm layer that is supposed to
be able to do mirroring and striping, but I'm told it's not
stable enough for "production" use.

Sam
Andre Oppermann
2004-12-02 17:41:53 UTC
Permalink
Sam wrote:
> On Thu, 2 Dec 2004, Andre Oppermann wrote:
>
>> Scott Long wrote:
>>
>>> 5. Clustered FS support. SANs are all the rage these days, and
>>> clustered filesystems that allow data to be distributed across many
>>> storage enpoints and accessed concurrently through the SAN are very
>>> powerful. RedHat recently bought Sistina and re-opened the GFS source
>>> code, so exploring this would be very interesting.
>>
>> There are certain steps that can be be taken one at a time. For example
>> it should be relatively easy to mount snapshots (ro) from more than one
>> machine. Next step would be to mount a full 'rw' filesystem as 'ro' on
>> other boxes. This would require cache and sector invalidation
>> broadcasting
>> from the 'rw' box to the 'ro' mounts. The holy grail of course is to
>> mount
>> the same filesystem 'rw' on more than one box, preferrably more than two.
>> This requires some more involved synchronization and locking on top of
>> the
>> cache invalidation. And make sure that the multi-'rw' cluster stays
>> alive
>> if one of the participants freezes and doesn't respond anymore.
>>
>> Scrolling through the UFS/FFS code I think the first one is 2-3 days of
>> work. The second 2-4 weeks and the third 2-3 month to get it right.
>> If someone would throw up the money...
>
> You might also design in consideration for data redundancy. Right now
> GFS largely relies on the SAN box to export already redundant RAID
> disks. GFS sits on a "cluster aware" lvm layer that is supposed to
> be able to do mirroring and striping, but I'm told it's not
> stable enough for "production" use.

Data redundancy would require a UFS/FFS redesign. I'm 'only' talking
about enhancing UFS/FFS but keeping anything ondisk the same (plus
some more elements).

--
Andre
Kamal R. Prasad
2004-12-02 18:02:54 UTC
Permalink
Andre Oppermann wrote:

> Sam wrote:
>
>> On Thu, 2 Dec 2004, Andre Oppermann wrote:
>>
>>> Scott Long wrote:
>>>
>>>> 5. Clustered FS support. SANs are all the rage these days, and
>>>> clustered filesystems that allow data to be distributed across many
>>>> storage enpoints and accessed concurrently through the SAN are very
>>>> powerful. RedHat recently bought Sistina and re-opened the GFS source
>>>> code, so exploring this would be very interesting.
>>>
>>>
>>> There are certain steps that can be be taken one at a time. For
>>> example
>>> it should be relatively easy to mount snapshots (ro) from more than one
>>> machine. Next step would be to mount a full 'rw' filesystem as 'ro' on
>>> other boxes. This would require cache and sector invalidation
>>> broadcasting
>>> from the 'rw' box to the 'ro' mounts. The holy grail of course is
>>> to mount
>>> the same filesystem 'rw' on more than one box, preferrably more than
>>> two.
>>> This requires some more involved synchronization and locking on top
>>> of the
>>> cache invalidation. And make sure that the multi-'rw' cluster stays
>>> alive
>>> if one of the participants freezes and doesn't respond anymore.
>>>
>>> Scrolling through the UFS/FFS code I think the first one is 2-3 days of
>>> work. The second 2-4 weeks and the third 2-3 month to get it right.
>>> If someone would throw up the money...
>>
>>
>> You might also design in consideration for data redundancy. Right now
>> GFS largely relies on the SAN box to export already redundant RAID
>> disks. GFS sits on a "cluster aware" lvm layer that is supposed to
>> be able to do mirroring and striping, but I'm told it's not
>> stable enough for "production" use.
>
>
> Data redundancy would require a UFS/FFS redesign. I'm 'only' talking
> about enhancing UFS/FFS but keeping anything ondisk the same (plus
> some more elements).
>
If you add redundancy code into UFS/FFS, that will slow down its
performance (even for those not seeking redundancy).
A better way would be to have another filesystem implementation like
VxFS (veritas filesystem). Im not sure if they have published papers/put
their techniques into public domain.

regards
-kamal
Stephan Uphoff
2004-12-02 21:27:18 UTC
Permalink
On Thu, 2004-12-02 at 09:41, Andre Oppermann wrote:
> Scott Long wrote:
> > 5. Clustered FS support. SANs are all the rage these days, and
> > clustered filesystems that allow data to be distributed across many
> > storage enpoints and accessed concurrently through the SAN are very
> > powerful. RedHat recently bought Sistina and re-opened the GFS source
> > code, so exploring this would be very interesting.
>
> There are certain steps that can be be taken one at a time. For example
> it should be relatively easy to mount snapshots (ro) from more than one
> machine. Next step would be to mount a full 'rw' filesystem as 'ro' on
> other boxes. This would require cache and sector invalidation broadcasting
> from the 'rw' box to the 'ro' mounts.

Mhhh .. if you plan to invalidate at the disk block cache layer then you
will run into race conditions with UFS/FFS (Especially with remove
operations)
I was once called in to evaluate such a multiple reader/single writer
system based on an UFS like file system and block layer invalidation and
had to convince management to kill it. (It appeared to work and actually
made it though internal and customer acceptance testing before failing
horrible in the field).

If you send me more details on your proposed cache and sector
invalidation/cluster design I will be happy to review it.


> The holy grail of course is to mount
> the same filesystem 'rw' on more than one box, preferrably more than two.
> This requires some more involved synchronization and locking on top of the
> cache invalidation. And make sure that the multi-'rw' cluster stays alive
> if one of the participants freezes and doesn't respond anymore.
>
> Scrolling through the UFS/FFS code I think the first one is 2-3 days of
> work. The second 2-4 weeks and the third 2-3 month to get it right.
> If someone would throw up the money...
Scott Long
2004-12-02 21:43:20 UTC
Permalink
Stephan Uphoff wrote:
> On Thu, 2004-12-02 at 09:41, Andre Oppermann wrote:
>
>>Scott Long wrote:
>>
>>>5. Clustered FS support. SANs are all the rage these days, and
>>>clustered filesystems that allow data to be distributed across many
>>>storage enpoints and accessed concurrently through the SAN are very
>>>powerful. RedHat recently bought Sistina and re-opened the GFS source
>>>code, so exploring this would be very interesting.
>>
>>There are certain steps that can be be taken one at a time. For example
>>it should be relatively easy to mount snapshots (ro) from more than one
>>machine. Next step would be to mount a full 'rw' filesystem as 'ro' on
>>other boxes. This would require cache and sector invalidation broadcasting
>>from the 'rw' box to the 'ro' mounts.
>
>
> Mhhh .. if you plan to invalidate at the disk block cache layer then you
> will run into race conditions with UFS/FFS (Especially with remove
> operations)
> I was once called in to evaluate such a multiple reader/single writer
> system based on an UFS like file system and block layer invalidation and
> had to convince management to kill it. (It appeared to work and actually
> made it though internal and customer acceptance testing before failing
> horrible in the field).
>
> If you send me more details on your proposed cache and sector
> invalidation/cluster design I will be happy to review it.
>
>
>
>>The holy grail of course is to mount
>>the same filesystem 'rw' on more than one box, preferrably more than two.
>>This requires some more involved synchronization and locking on top of the
>>cache invalidation. And make sure that the multi-'rw' cluster stays alive
>>if one of the participants freezes and doesn't respond anymore.
>>
>>Scrolling through the UFS/FFS code I think the first one is 2-3 days of
>>work. The second 2-4 weeks and the third 2-3 month to get it right.
>>If someone would throw up the money...
>
>

Although I don't know the specifics of your experience, I can easily
imagine how hard it would be to make this work on UFS. Common
operations like walking a file path to the root are nearly impossible to
do reliably without an overbearing amount of synchronization. Then you
have all of the problems synchronizing buffered data and metadata.
Softupdates would be a nightmare, if not impossible.

Scott
Andre Oppermann
2004-12-02 22:37:06 UTC
Permalink
Scott Long wrote:
> Stephan Uphoff wrote:
>
>> On Thu, 2004-12-02 at 09:41, Andre Oppermann wrote:
>>
>>> The holy grail of course is to mount
>>> the same filesystem 'rw' on more than one box, preferrably more than
>>> two.
>>> This requires some more involved synchronization and locking on top
>>> of the
>>> cache invalidation. And make sure that the multi-'rw' cluster stays
>>> alive
>>> if one of the participants freezes and doesn't respond anymore.
>>>
>>> Scrolling through the UFS/FFS code I think the first one is 2-3 days of
>>> work. The second 2-4 weeks and the third 2-3 month to get it right.
>>> If someone would throw up the money...
>
> Although I don't know the specifics of your experience, I can easily
> imagine how hard it would be to make this work on UFS. Common
> operations like walking a file path to the root are nearly impossible to
> do reliably without an overbearing amount of synchronization. Then you
> have all of the problems synchronizing buffered data and metadata.

You don't do it the fully synchronized way. The semantics will be somewhat
like with NFS. Reading in the filesystem does not invoke synchronization.
Only writing, or actually intending to write something, requires synchro-
nization with all other machines in the filesystem cluster. Synchronization
ensures that writes to a directory or file are properly serialized and that
caches are invalidated at the same time.

> Softupdates would be a nightmare, if not impossible.

To the contrary. It provides a nice place to link code into and it helps
to keep performance up to good levels. Any inode changes entering the
softdep code would cause a message to all other machines informing them
of the change. If another one wants to update the same inode or something
dependend on it it has to wait until you have written it to disk. His
backnotification would of course move this inode to the front of the softdep
work queue to not stall your request.

As long as you don't want to have mmap() work across machines with contents
in memory but not yet written to disk things stay pretty much sane.

--
Andre
Andre Oppermann
2004-12-02 22:24:03 UTC
Permalink
Stephan Uphoff wrote:
> On Thu, 2004-12-02 at 09:41, Andre Oppermann wrote:
>
>>Scott Long wrote:
>>
>>>5. Clustered FS support. SANs are all the rage these days, and
>>>clustered filesystems that allow data to be distributed across many
>>>storage enpoints and accessed concurrently through the SAN are very
>>>powerful. RedHat recently bought Sistina and re-opened the GFS source
>>>code, so exploring this would be very interesting.
>>
>>There are certain steps that can be be taken one at a time. For example
>>it should be relatively easy to mount snapshots (ro) from more than one
>>machine. Next step would be to mount a full 'rw' filesystem as 'ro' on
>>other boxes. This would require cache and sector invalidation broadcasting
>>from the 'rw' box to the 'ro' mounts.
>
> Mhhh .. if you plan to invalidate at the disk block cache layer then you
> will run into race conditions with UFS/FFS (Especially with remove
> operations)
> I was once called in to evaluate such a multiple reader/single writer
> system based on an UFS like file system and block layer invalidation and
> had to convince management to kill it. (It appeared to work and actually
> made it though internal and customer acceptance testing before failing
> horrible in the field).
>
> If you send me more details on your proposed cache and sector
> invalidation/cluster design I will be happy to review it.

It obviously doesn't work only the disk block level. For the rw+ro(n) case
you have to invalidate updated/changed inodes (file and directory inodes)
as well as associated data blocks. Alternatively you could invalidate all
related data blocks together with the inode but that would kill performance
for files that are simply appended (like log files).

--
Andre
Divacky Roman
2004-12-02 16:01:25 UTC
Permalink
des@ raised question realting to implementition of anticipatory scheduler..

http://www.cs.rice.edu/~ssiyer/r/antsched/

shouldnt this be integrated or something?

On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote:
> All,
>
> I know that I said last month that we were going to stop promising
> specific features for the next major release. However, I'd like to
> throw out a list of things that would be really nice to have in the
> future, whether its 6.0 or 7.0 or whatever. Most of these tasks are
> not trivial, but I hope that talking about them will encourage some
> interest. These are in no particular priority order. I'd also be
> thrilled if someone wanted to dress this list up in docbook and add
> it to the webpage. While this is just my personal list, I'd welcome
> other additions to it (in the sense of significant projects, not just
> individual PRs or bug fixes that one might be interested in).
>
> 1. Keyboard multiplexer. We are running into problems with making
> ps/2 and USB/bluetooth keyboards work together and work with KVMs.
> Having a virtual keyboard device that multiplexes the various real
> keyboard devices and handles hotplug can solve this mess pretty
> effectively. I know that there has been a lot of talk about this on
> mailing lists recently but I don't know how much progress is being made
> so I'm listing it here.
>
> 2. New installer. I know some people still consider this a joke, but
> the reality is that sysinstall is no longer state of the art. It's
> fairly good at the simple task that it does, but it's becoming harder
> and harder to fix bugs and extend functionality in it. It's also
> fairly unfriendly to those of us who haven't been using it since 1995.
> The DFly folks have some very interesting work in this area
> (www.bsdinstaller.com) and it would be very good to see if we can
> collaborate with them on it.
>
> 3. Native PCI Express support. I keep on hoping to take care of this,
> but I never seem to have the time to get past designing it. This task
> includes 3 parts that are mostly independent. The first is support for
> the extended PCI config space and memio access method, the second is
> MSI, and the third is link QOS management. If anyone is interested
> here, please let me know.
>
> 4. Journaled filesystem. While we can debate the merits of speed and
> data integrety of journalling vs. softupdates, the simple fact remains
> that softupdates still requires a fsck run on recovery, and the
> multi-terabyte filesystems that are possible these days make fsck a very
> long and unpleasant experience, even with bg-fsck. There was work at
> some point at RPI to add journaling to UFS, but there hasn't been much
> status on that in a long time. There have also been proposals and
> works-in-progress to port JFS, ReiserFS, and XFS. Some of these efforts
> are still alive, but they need to be seen through to completion. But at
> the risk of opening a can of worms here, I'll say that it's also
> important to explore non-GPL alternatives.
>
> 5. Clustered FS support. SANs are all the rage these days, and
> clustered filesystems that allow data to be distributed across many
> storage enpoints and accessed concurrently through the SAN are very
> powerful. RedHat recently bought Sistina and re-opened the GFS source
> code, so exploring this would be very interesting.
>
> 6. Overhaul CAM, add iSCSI. CAM is very parallel-SCSI centric right
> now. I have some work-in-progress in Perforce to address this, but it's
> pretty minimal. The parallel SCSI knowledge needs to be separated out
> and the stack need to be able to cleanly deal with iSCSI, SCSI, SAS, and
> maybe even ATA transports. There is a Lucent implementation of iSCSI
> for FreeBSD 4.x that could be a useful reference, though it's a
> monolithic stack that doesn't really address the shortcomings of CAM.
> Having iSCSI infrastructure that supported both hardware and software
> implementations would be ideal.
>
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-***@freebsd.org"
Jon Noack
2004-12-02 17:50:50 UTC
Permalink
Divacky Roman wrote:
> des@ raised question realting to implementition of anticipatory
> scheduler..
>
> http://www.cs.rice.edu/~ssiyer/r/antsched/
>
> shouldnt this be integrated or something?

I would love to see this happen. It looks like a lot of work is going
into revamping storage for 6.x, and this would be great addition.

Dr. Druschel was my Operating Systems prof at Rice. He was a good
teacher, quite knowledgeable, and a nice guy. I remember talking about
anticipatory scheduling in class... ah, fond memories.

Jon
Eric Kjeldergaard
2004-12-02 19:48:54 UTC
Permalink
> 4. Journaled filesystem. While we can debate the merits of speed and
> data integrety of journalling vs. softupdates, the simple fact remains
> that softupdates still requires a fsck run on recovery, and the
> multi-terabyte filesystems that are possible these days make fsck a very
> long and unpleasant experience, even with bg-fsck. There was work at
> some point at RPI to add journaling to UFS, but there hasn't been much
> status on that in a long time. There have also been proposals and
> works-in-progress to port JFS, ReiserFS, and XFS. Some of these efforts
> are still alive, but they need to be seen through to completion. But at
> the risk of opening a can of worms here, I'll say that it's also
> important to explore non-GPL alternatives.

A thread (http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040904.html
)happens to be talking about ro support for the ReiserFS. After
having used this for quite some time in a Linux environment, I can't
help but notice that it seriously outperforms any other filesystem
I've tried on large numbers of littlish files. A beautiful
application that I've rather wanted to try for a while was this on the
ports tree.

The stage of the current implementation is, as I said, read-only.
Further, it's currently i386 only. However, I think that there is
enough interest in this new (and relatively exciting) filesystem that
we may be able to find some developers with time (Possibly including
myself) and desire to try to implement write support and do some
porting. To ease any qualms with regards to licensing, it appears
(http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040998.html)
that the current implementation is BSD licensed.

--
If I write a signature, my emails will appear more personalised.
Robert Huff
2004-12-02 20:34:52 UTC
Permalink
Marcel Moolenaar writes:

> > 1. Keyboard multiplexer.
>
> I actually fail to stop thinking about a complete syscons and
> pcvt replacement. You know, the one and only console
> implementation that makes all others obsolete. Big plans, little
> time, yada yada yada...

As long as we're talking about keyboards ... may I add "Get the
boot code to recognize USB keyboards."
(Unless this has already happened and I missed the meno.
Again.)


Robert Huff
Brooks Davis
2004-12-02 20:51:24 UTC
Permalink
On Thu, Dec 02, 2004 at 03:34:52PM -0500, Robert Huff wrote:
>
> Marcel Moolenaar writes:
>
> > > 1. Keyboard multiplexer.
> >
> > I actually fail to stop thinking about a complete syscons and
> > pcvt replacement. You know, the one and only console
> > implementation that makes all others obsolete. Big plans, little
> > time, yada yada yada...
>
> As long as we're talking about keyboards ... may I add "Get the
> boot code to recognize USB keyboards."
> (Unless this has already happened and I missed the meno.
> Again.)

The code reconginzes the keyboard, you just can't use it by default.
That's what the mux will fix.

-- Brooks

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
Scott Long
2004-12-02 20:50:31 UTC
Permalink
Robert Huff wrote:
> Marcel Moolenaar writes:
>
>
>> > 1. Keyboard multiplexer.
>>
>> I actually fail to stop thinking about a complete syscons and
>> pcvt replacement. You know, the one and only console
>> implementation that makes all others obsolete. Big plans, little
>> time, yada yada yada...
>
>
> As long as we're talking about keyboards ... may I add "Get the
> boot code to recognize USB keyboards."
> (Unless this has already happened and I missed the meno.
> Again.)
>
>
> Robert Huff
>

Are you talking about putting a minimal USB stack into the boot loader?
That _certainly_ cannot fit into boot0, and I doubt that it can fit into
boot1. It might be possible for boot2/BTX/loader, but that's also quite
a bit of work. I take it that your BIOS does not provide keyboard
emulation for you? If not, I guess that it makes it difficult to boot
to DOS.

Scott
Robert Huff
2004-12-02 21:49:04 UTC
Permalink
Scott Long writes:

> Are you talking about putting a minimal USB stack into the boot
> loader? That _certainly_ cannot fit into boot0, and I doubt that
> it can fit into boot1. It might be possible for
> boot2/BTX/loader, but that's also quite a bit of work.

As far as I know - and I would _love_ to be wrong - USB
keyboards are not recognized before the kernel proper loads. This
means I have to keep a PS2 keybaord attached to interrupt the
countdown and make the jump to sub-ligh\\\\\, er. single user. I
have no idea what stage of the boot process this is; all I know I
have to use two keyboards where I should only need one.

> I take it that your BIOS does not provide keyboard emulation for
> you? If not, I guess that it makes it difficult to boot to DOS.

The motherboard is an Asus P4S533 with an Award BIOS. I can't
take the machine down to check on any keyboard emulation settings.
(And the box has always been 100% Microsoft-free.)



Robert Huff
Peter Wemm
2004-12-03 00:21:17 UTC
Permalink
On Thursday 02 December 2004 01:49 pm, Robert Huff wrote:
> Scott Long writes:
> > Are you talking about putting a minimal USB stack into the boot
> > loader? That _certainly_ cannot fit into boot0, and I doubt that
> > it can fit into boot1. It might be possible for
> > boot2/BTX/loader, but that's also quite a bit of work.
>
> As far as I know - and I would _love_ to be wrong - USB
> keyboards are not recognized before the kernel proper loads. This
> means I have to keep a PS2 keybaord attached to interrupt the
> countdown and make the jump to sub-ligh\\\\\, er. single user. I
> have no idea what stage of the boot process this is; all I know I
> have to use two keyboards where I should only need one.
>
> > I take it that your BIOS does not provide keyboard emulation for
> > you? If not, I guess that it makes it difficult to boot to DOS.
>
> The motherboard is an Asus P4S533 with an Award BIOS. I can't
> take the machine down to check on any keyboard emulation settings.
> (And the box has always been 100% Microsoft-free.)

This is an ASUS bug, possibly a bug in the reference bioses. They have
a whitelist of MBR partition types to decide what to do about USB
keyboards.

What is supposed to happen is that the bios keyboard and video calls
work with the usb keyboard. Bioses also have a 'legacy' keyboard
hardware emulation to simulate PS/2 keyboard hardware using the usb
keyboard. This feature is meaninless to us in boot1 / loader / etc
because we are a normal bios client like msdos.

However, if the bios sees partition type 165 (FreeBSD), it freaks out
and completely shuts down all USB support. Even for the bios keyboard
service calls.

If you boot MSDOS, for example.. the bios keyboard service calls are not
disabled and keep working.

Asus seems to be the worst offender in this area recently. This
misfeature appeared on their newer Athlon64 boards and now you've
reported it on their P4 boards.. Grrrrr.
--
Peter Wemm - ***@wemm.org; ***@FreeBSD.org; ***@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Barney Wolff
2004-12-03 02:03:55 UTC
Permalink
On Thu, Dec 02, 2004 at 04:21:17PM -0800, Peter Wemm wrote:
>
> However, if the bios sees partition type 165 (FreeBSD), it freaks out
> and completely shuts down all USB support. Even for the bios keyboard
> service calls.
>
> If you boot MSDOS, for example.. the bios keyboard service calls are not
> disabled and keep working.

Pardon a naive question, but what would happen with a FreeBSD partition
whose type said something other than 165? What in fbsd checks the
partition type once booting starts?

--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
Scott Long
2004-12-03 02:26:09 UTC
Permalink
Barney Wolff wrote:
> On Thu, Dec 02, 2004 at 04:21:17PM -0800, Peter Wemm wrote:
>
>>However, if the bios sees partition type 165 (FreeBSD), it freaks out
>>and completely shuts down all USB support. Even for the bios keyboard
>>service calls.
>>
>>If you boot MSDOS, for example.. the bios keyboard service calls are not
>>disabled and keep working.
>
>
> Pardon a naive question, but what would happen with a FreeBSD partition
> whose type said something other than 165? What in fbsd checks the
> partition type once booting starts?
>

It's very a fundamental value for being able to find and mount the
partitions at boot.

Scott
Julian Elischer
2004-12-03 06:13:54 UTC
Permalink
Scott Long wrote:
> Robert Huff wrote:
>
>> Marcel Moolenaar writes:
>>
>>
>>> > 1. Keyboard multiplexer.
>>>
>>> I actually fail to stop thinking about a complete syscons and
>>> pcvt replacement. You know, the one and only console
>>> implementation that makes all others obsolete. Big plans, little
>>> time, yada yada yada...
>>
>>
>>
>> As long as we're talking about keyboards ... may I add "Get the
>> boot code to recognize USB keyboards."
>> (Unless this has already happened and I missed the meno.
>> Again.)
>>
>>
>> Robert Huff
>>
>
> Are you talking about putting a minimal USB stack into the boot loader?
> That _certainly_ cannot fit into boot0, and I doubt that it can fit into
> boot1. It might be possible for boot2/BTX/loader, but that's also quite
> a bit of work. I take it that your BIOS does not provide keyboard
> emulation for you? If not, I guess that it makes it difficult to boot
> to DOS.

that's what "Legacy USB support" is in the BIOS.


>
> Scott
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
Josh Tolbert
2004-12-02 21:16:01 UTC
Permalink
On Thu, Dec 02, 2004 at 03:34:52PM -0500, Robert Huff wrote:
>
> Marcel Moolenaar writes:
>
> > > 1. Keyboard multiplexer.
> >
> > I actually fail to stop thinking about a complete syscons and
> > pcvt replacement. You know, the one and only console
> > implementation that makes all others obsolete. Big plans, little
> > time, yada yada yada...
>
> As long as we're talking about keyboards ... may I add "Get the
> boot code to recognize USB keyboards."
> (Unless this has already happened and I missed the meno.
> Again.)
>
>
> Robert Huff

As long as we're talking about keyboards, re-vamping the console driver, etc.,
can something be done with psm? FreeBSD is the only OS that requires me to
pass flags to psm to get my mouse to behave properly on my KVM switch, and the
flag I use (0x200) forces "true" PS/2 mode, disabling the wheel and such.

Granted, the only other OSes I've had on KVM switches with FreeBSD machines
are Windows, Linux and OS/X, but it still seems like something's amiss with
psm.

Thanks,
Josh
--
Josh Tolbert
***@puresimplicity.net || http://www.puresimplicity.net/~hemi/

If your sysadmin's not being fascist, you're paying him too much.
--Sam Greenfield
Tai-hwa Liang
2004-12-06 06:04:26 UTC
Permalink
On Thu, 2 Dec 2004, Josh Tolbert wrote:
> On Thu, Dec 02, 2004 at 03:34:52PM -0500, Robert Huff wrote:
>> Marcel Moolenaar writes:
>>
>>> > 1. Keyboard multiplexer.
>>>
>>> I actually fail to stop thinking about a complete syscons and
>>> pcvt replacement. You know, the one and only console
>>> implementation that makes all others obsolete. Big plans, little
>>> time, yada yada yada...
>>
>> As long as we're talking about keyboards ... may I add "Get the
>> boot code to recognize USB keyboards."
>> (Unless this has already happened and I missed the meno.
>> Again.)
>>
>>
>> Robert Huff
>
> As long as we're talking about keyboards, re-vamping the console driver, etc.,
> can something be done with psm? FreeBSD is the only OS that requires me to
> pass flags to psm to get my mouse to behave properly on my KVM switch, and the
> flag I use (0x200) forces "true" PS/2 mode, disabling the wheel and such.
>
> Granted, the only other OSes I've had on KVM switches with FreeBSD machines
> are Windows, Linux and OS/X, but it still seems like something's amiss with
> psm.
>
> Thanks,
> Josh

Agreed. That's exactly the same workaround I have to apply on my
device.hints. Without 0x200, my PS/2 mouse doesn't work with
the Lextek ConsoleManager Smart KVM Switch.

kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000

And yes, Linux/Windoze doesn't need any tweaking to get such
combination work....
Valentin Nechayev
2004-12-02 20:47:36 UTC
Permalink
Wed, Dec 01, 2004 at 15:02:40, scottl wrote about "My project wish-list for the next 12 months":

[...]
> 2. New installer. I know some people still consider this a joke, but
> the reality is that sysinstall is no longer state of the art. It's
> fairly good at the simple task that it does, but it's becoming harder
> and harder to fix bugs and extend functionality in it. It's also
> fairly unfriendly to those of us who haven't been using it since 1995.
> The DFly folks have some very interesting work in this area
> (www.bsdinstaller.com) and it would be very good to see if we can
> collaborate with them on it.

If we're going to discuss admin-friendiness...

- Resplit distribution sets. It's simply shame when unpacking base overwrites
existing log files (e.g. during binary upgrade).
At least /etc and /var/log _must_ be separated. Also, I consider openbsd
scheme to be pleasant: separate build tools set (gcc, binutils, etc.)
from main functioning set.
As maximum, convert them into packages and register along with ports.

- Fix the most ugly sysinstall features. E.g. setting active flags on all
partitions by default, along with setting MBR, leads to unbootable system.
This was _constant_ students' error on FreeBSD administration courses.

- Provide more administrative tools. For now, one can't see interface queue
lengths, netgraph queue lens, tune their sizes, calculate memory occupied
by a bunch of processes without multiple counting shared pages...


-netch-
Brooks Davis
2004-12-02 21:01:38 UTC
Permalink
On Thu, Dec 02, 2004 at 10:47:36PM +0200, Valentin Nechayev wrote:
> Wed, Dec 01, 2004 at 15:02:40, scottl wrote about "My project wish-list for the next 12 months":
>
> [...]
> > 2. New installer. I know some people still consider this a joke, but
> > the reality is that sysinstall is no longer state of the art. It's
> > fairly good at the simple task that it does, but it's becoming harder
> > and harder to fix bugs and extend functionality in it. It's also
> > fairly unfriendly to those of us who haven't been using it since 1995.
> > The DFly folks have some very interesting work in this area
> > (www.bsdinstaller.com) and it would be very good to see if we can
> > collaborate with them on it.
>
> If we're going to discuss admin-friendiness...
>
> - Resplit distribution sets. It's simply shame when unpacking base overwrites
> existing log files (e.g. during binary upgrade).
> At least /etc and /var/log _must_ be separated. Also, I consider openbsd
> scheme to be pleasant: separate build tools set (gcc, binutils, etc.)
> from main functioning set.
> As maximum, convert them into packages and register along with ports.

The log files shouldn't be there at all. I'm planning to remove all of
them from the distribution sets and do the creation during boot.

-- Brooks

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
Jean-Sébastien Pédron
2004-12-02 21:33:12 UTC
Permalink
Eric Kjeldergaard wrote:
>> 4. Journaled filesystem.
>
> The stage of the current implementation is, as I said, read-only.
> Further, it's currently i386 only.

In theory, it shouldn't be tied to i386, but I never tested it somewhere
else unfortunately.

> However, I think that there is enough interest in this new (and
> relatively exciting) filesystem that we may be able to find some
> developers with time (Possibly including myself) and desire to try to
> implement write support and do some porting. To ease any qualms
> with regards to licensing, it appears
> (http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040998.html)
> that the current implementation is BSD licensed.

Not exactly. Only the mount_reiserfs command is under BSD. The kernel
module is GPL.

I don't know neither JFS nor XFS, but Reiser4 may be a great candidate
too (the current port is ReiserFS 3.6 only). It sure doesn't have the
maturity of ReiserFS but brings nice features.

Jean-Seb
Eric Kjeldergaard
2004-12-02 21:41:35 UTC
Permalink
> >> 4. Journaled filesystem.
> >
> > The stage of the current implementation is, as I said, read-only.
> > Further, it's currently i386 only.
>
> In theory, it shouldn't be tied to i386, but I never tested it somewhere
> else unfortunately.
>

Got that from the reiserfs port which says it doesn't compile other
than under i386.

> > However, I think that there is enough interest in this new (and
> > relatively exciting) filesystem that we may be able to find some
> > developers with time (Possibly including myself) and desire to try to
> > implement write support and do some porting. To ease any qualms
> > with regards to licensing, it appears
> > (http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040998.html)
> > that the current implementation is BSD licensed.
>
> Not exactly. Only the mount_reiserfs command is under BSD. The kernel
> module is GPL.
>

Oh, I'm sorry. I guess I read quickly and w/o thinking enough. I
suppose that would put is near square 1.

> I don't know neither JFS nor XFS, but Reiser4 may be a great candidate
> too (the current port is ReiserFS 3.6 only). It sure doesn't have the
> maturity of ReiserFS but brings nice features.

That would be nice if the support could be gathered for it. I do like
it better than XFS (which I've tried).

--
If I write a signature, my emails will appear more personalised.
Peter Wemm
2004-12-03 00:24:21 UTC
Permalink
On Wednesday 01 December 2004 05:17 pm, Foxfair Hu wrote:
> On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote:
> > All,
>
> [....]
>
> > 1. Keyboard multiplexer. We are running into problems with making
> > ps/2 and USB/bluetooth keyboards work together and work with KVMs.
> > Having a virtual keyboard device that multiplexes the various real
> > keyboard devices and handles hotplug can solve this mess pretty
> > effectively. I know that there has been a lot of talk about this
> > on mailing lists recently but I don't know how much progress is
> > being made so I'm listing it here.
>
> How about reuse NetBSD's wscons ? I've kept an eye on it and
> thought it should be a good start for FreeBSD.

Only if it has 100% identical look/feel to syscons. ie: same key maps,
same ioctl's, same Xserver interface, same escape codes, etc. If not,
then over my dead body!

--
Peter Wemm - ***@wemm.org; ***@FreeBSD.org; ***@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Scott Long
2004-12-03 00:29:17 UTC
Permalink
Peter Wemm wrote:
> On Wednesday 01 December 2004 05:17 pm, Foxfair Hu wrote:
>
>>On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote:
>>
>>>All,
>>
>>[....]
>>
>>
>>>1. Keyboard multiplexer. We are running into problems with making
>>>ps/2 and USB/bluetooth keyboards work together and work with KVMs.
>>>Having a virtual keyboard device that multiplexes the various real
>>>keyboard devices and handles hotplug can solve this mess pretty
>>>effectively. I know that there has been a lot of talk about this
>>>on mailing lists recently but I don't know how much progress is
>>>being made so I'm listing it here.
>>
>> How about reuse NetBSD's wscons ? I've kept an eye on it and
>>thought it should be a good start for FreeBSD.
>
>
> Only if it has 100% identical look/feel to syscons. ie: same key maps,
> same ioctl's, same Xserver interface, same escape codes, etc. If not,
> then over my dead body!
>

What if it's 100% identical except for the [Space] key, which becomes
the console pause key?

=-)

Scott
J.R. Oldroyd
2004-12-03 02:49:04 UTC
Permalink
How about some form of streamlined video input support?

I realize Linux's v4l model doesn't fit too well here, but what
they have done there provides support for all sorts of common video
devices, and makes them all available to pretty much any program that
wants video input.

FreeBSD is far behind in this area.

-jr


On Dec 01, 15:02, Scott Long wrote:
> All,
>
> I know that I said last month that we were going to stop promising
> specific features for the next major release. However, I'd like to
> throw out a list of things that would be really nice to have in the
> future, whether its 6.0 or 7.0 or whatever. Most of these tasks are
> not trivial, but I hope that talking about them will encourage some
> interest. These are in no particular priority order. I'd also be
> thrilled if someone wanted to dress this list up in docbook and add
> it to the webpage. While this is just my personal list, I'd welcome
> other additions to it (in the sense of significant projects, not just
> individual PRs or bug fixes that one might be interested in).
>
Peter Ross
2004-12-09 05:44:29 UTC
Permalink
Scott Long, Wed Dec 1 14:02:28 PST 2004

> 5. Clustered FS support. SANs are all the rage these days, and
> clustered filesystems that allow data to be distributed across many
> storage enpoints and accessed concurrently through the SAN are very
> powerful. RedHat recently bought Sistina and re-opened the GFS source
> code, so exploring this would be very interesting.

As we see there are some unfinished pieces (BTW: The freebsd-cluster list
is very quiet).

I browsed through some of them. It is difficult to judge how far they away
from beeing mature.

There is:

1) 2x AFS
(BSD project, OpenAFS)

2) iSCSI
The Lucent code

Peter Blok seems to have some ideas comparable to mine when I started
to play with ***@FreeBSD when I was unemployed last year.
(Unfortunatelly not long enough;-)

My naive idea for network mirroring to get basic SAN multipath
functionality is to combine vinum + iSCSI. Is it achievable?

3) NFSv4

NFS Version 4 is part of FreeBSD now. There is an idea to implement
replication but AFAIK it is not implemented yet (I have to check).

At least there is a whitepaper:
http://www.citi.umich.edu/projects/nfsv4/reports/replication.pdf

It could be used as a frontend for concurrent access (NFSv4 provides
_real_ locking including byterange locking etc.)

There are some ideas to implement concurrent access in UFS.. Is it the
right place? (Hint: There are many Linux filesystems with beautiful
features but it is hard to find a reliable one - possibly because the
featuritis makes them too complex?)

Maybe it is better to have one specialised filesystem (see Veritas as
already mentioned). Or a layer above the "real" FS.

BTW: AFAIK ReiserFS (suggested as a FreeBSD port) does not support ACLs..

Regards
Peter
Continue reading on narkive:
Loading...