Re: OT: package scripts (was Re: software packaging and ReiserFS v4)
I'm excited about your packaging system. I hope you make something very useful. Here are some ideas I have had about packaging and operating system design; they might be interesting to you. Comments, suggestion, other ideas are wanted. Ideally, each user's home dir would mirror the system directories (i.e. users have their own bin, share, lib and var). This way, users can install a package (and it would be local to them) and root could install the exact same package (and it would be global to the system). Right now, on every distribution, only root can install packages; this is a place where a new packaging system could have huge advantages. Ideally, users' directories would get unioned to system's directories (in their namespace) upon login, so / would be their "home", /bin would be system's bin plus user's bin, etc. This way programs ALWAYS know the "right path" to everything (which has always been an annoying problem in Unix). Packages contain file sets only. This avoids side-effects of scripts. Well-designed programs do not need pre- and post-install scripts. If you want to install apache, say as www user, root would create that user, switch users to www, and then install apache as www. /sbin would go away; all sbin programs go to appropriate bin directories (because non-root users often need programs like fdisk, etc). /etc, /bin, /lib and /boot all have the files only necessary for bootup. Users can have an rc.d script directory in /etc (who gets to have rc.d scripts would be up to the sys admin) for launching services upon runlevel changes. Perhaps it would be better to put these dirs as /boot/bin, /boot/lib, etc, and use /bin for system-wide bin (i.e., like the present /usr/bin). /share/etc-defaults would contain default configurations, instead of cluttering up /etc (which is just stuff needed for booting and launching services). /share/etc-defaults could be mounted below user's /etc. (optional) /share/etc-mandatory could be mounted above user's /etc, for settings users should not be able to change (sometimes called "lock-down"). Environment variables are replaced by files, ala Plan 9. Instead of $EDITOR have /etc/default-applications/text-editor, web-browser, etc. TIdeally no programs should use environment variables for configuration; their existence is not obvious to the user, and neither is their possible values. (Shell scripts of course would still use env vars.) Programs should watch their configuration files for changes, to achive that instant-apply effect. I'm most excited for that once we have a stable Reiser4 system with files as dirs, it should be easy to write a universal configurator tool using files as keys.
OT: package scripts (was Re: software packaging and ReiserFS v4)
2003-09-05T16:18:06 Ragnar Kj?rstad: > I think if scripts were to be removed from the packaging system > you would have to add a package-feature for every single thing > that scripts are currently used for. Ok, you've convinced me to this extent: when I get to a point where I have to add such capabilities to my new packaging tool, they will be added by the ability to invoke canned reusable scripts that are part of the packaging system, not one-off per-package scripts. -Bennett pgp0.pgp Description: PGP signature
Re: software packaging and ReiserFS v4
On Fri, Sep 05, 2003 at 10:18:06PM +0200, Ragnar Kj?rstad wrote: > On Fri, Sep 05, 2003 at 12:44:13PM -0700, Mike Fedyk wrote: > > On Fri, Sep 05, 2003 at 01:15:41PM -0500, Grant Miner wrote: > > > If you are making a packaging system, I recommend you do not allow > > > scipts, since they open up a whole can of worms. (They're impossible to > > > invert, introduce security problems, make additional work for GUI > > > package managers, and cause too many problems.) > > > > What do you replace them with then? > > I think if scripts were to be removed from the packaging system you > would have to add a package-feature for every single thing that scripts > are currently used for. > > If you look through a collection of packages I think you will find that > they typically do things like: > - create users > - start / stop deamons > and so on. > > So the package-system would need a way to specify that a user is part of > the package (that would be very easy with a /etc/passwd.d-system) and > that deamons that are part of the package should be started at install > and stopped at uninstall-time. > > There are probably dozens of other examples of common operations - and > you would not be able to remove the script-feature unless 99% of what > they are used for is not needed anymore - so it's a complicated task. Great, so now you have a scripting language in the installer. What did you just achieve? If you want gui integration of the scripts, just make nice wrappers of the standard unix utilities that create a window saying "creating user x", or prompting the user for data, or printing a notice. You could probably even take the ncurses library, and add the wrappers there. But let the people who want to do this choose the best way...
Re: software packaging and ReiserFS v4
On Fri, Sep 05, 2003 at 12:44:13PM -0700, Mike Fedyk wrote: > On Fri, Sep 05, 2003 at 01:15:41PM -0500, Grant Miner wrote: > > If you are making a packaging system, I recommend you do not allow > > scipts, since they open up a whole can of worms. (They're impossible to > > invert, introduce security problems, make additional work for GUI > > package managers, and cause too many problems.) > > What do you replace them with then? I think if scripts were to be removed from the packaging system you would have to add a package-feature for every single thing that scripts are currently used for. If you look through a collection of packages I think you will find that they typically do things like: - create users - start / stop deamons and so on. So the package-system would need a way to specify that a user is part of the package (that would be very easy with a /etc/passwd.d-system) and that deamons that are part of the package should be started at install and stopped at uninstall-time. There are probably dozens of other examples of common operations - and you would not be able to remove the script-feature unless 99% of what they are used for is not needed anymore - so it's a complicated task. -- Ragnar Kjørstad
Re: software packaging and ReiserFS v4
On Fri, Sep 05, 2003 at 01:15:41PM -0500, Grant Miner wrote: > If you are making a packaging system, I recommend you do not allow > scipts, since they open up a whole can of worms. (They're impossible to > invert, introduce security problems, make additional work for GUI > package managers, and cause too many problems.) What do you replace them with then?
Re: software packaging and ReiserFS v4
If you are making a packaging system, I recommend you do not allow scipts, since they open up a whole can of worms. (They're impossible to invert, introduce security problems, make additional work for GUI package managers, and cause too many problems.)
Re: Reiser4 input/output errors...
Its a fresh filesystem, on a brand new drive (week old?), and if I put ext3 on the exact same partition, it works fine. The only time I see any errors is when I stick reiser4 on the partition and go through the steps explained in my first email. I even ran badblock on the partition and it didn't turn up anything. Just let me know what steps you want me to take to help you debug this. On Fri, 2003-09-05 at 01:20, Yury Umanets wrote: > On Thu, 2003-09-04 at 23:52, Mike Benoit wrote: > > [EMAIL PROTECTED] root]# debugfs.reiser4 -t /dev/hda8 > > debugfs.reiser4 0.4.12 > > Copyright (C) 2001, 2002, 2003 by Hans Reiser, licensing governed by > > reiser4progs/COPYING. > > > > NODE (21) LEVEL=2 ITEMS=1 SPACE=4020 MKFS=0x103e447b > > FLUSH=0x4001b901 > > (0) NODEPTR PLUGIN=nodeptr40 LEN=8, KEY=[29:1:0:2a:0:SD] UNITS=1 > > [22] > > > > NODE (22) LEVEL=1 ITEMS=2 SPACE=3838 MKFS=0x103e447b > > FLUSH=0xbfffe578 > > (0) STATDATA PLUGIN=stat40 LEN=48, KEY=[29:1:0:2a:0:SD] UNITS=1 > > exts: 2 > > mask: 0x3 > > plugin: sdext_lw > > offset: 2 > > len:14 > > mode: drwxr-xr-x > > nlink: 3 > > size: 2 > > plugin: sdext_unix > > offset: 16 > > len:32 > > uid:0 > > gid:0 > > atime: Tue Sep 2 09:39:26 2003 > > mtime: Tue Sep 2 09:39:26 2003 > > ctime: Tue Sep 2 09:39:26 2003 > > rdev: 0 > > bytes: 100 > > (1) CDE PLUGIN=cde_large LEN=102, KEY=[2a:0:0:0:0:NAME] UNITS=2 > > NR NAME OFFSET HASH SDKEY > > -- > > 0 . 54 : > > 291:02a > > 1 ..78 002e2e00: > > 291:02a > > > > > > Let me know if you need any more information. I'm also on IRC during PST > > business hours, if that would be better for you to debug this issue. > > > > On Wed, 2003-09-03 at 21:52, Yury Umanets wrote: > > > On Wed, 2003-09-03 at 19:45, Mike Benoit wrote: > > > > > > > > Can you run debugfs.reiser4 on /dev/hda8? What does it say? > > > > > > > > > > > Can you print the tree? > > > > > > debugfs.reiser4 -t /dev/hda8? > > Hm... That is strange. I supposed, that there should be lots of data. > And I guessed, that there something like tree corruption, which may be > discovered by tree printing. > > But this is fresh filesystem. Is it had IO errors on it? > > > > -- Best Regards, Mike Benoit NetNation Communications Inc. Systems Engineer Tel: 604-684-6892 or 888-983-6600 --- Disclaimer: Opinions expressed here are my own and not necessarily those of my employer
Re: dbench regression in 2.6
Steven Pratt wrote: Mike Fedyk wrote: On Thu, Sep 04, 2003 at 09:23:42AM -0500, Steven Pratt wrote: Vladimir Saveliev wrote: Hi On Wednesday 03 September 2003 23:04, Hans Reiser wrote: Steven Pratt wrote: Is anyone looking into the dbench multitheaded regression in 2.6 that I reported here a couple of weeks ago? Sorry, I was unable to find your report in mail archives. Could you, please, remind what is the problem? I don't see any change in the latest trees. The problem showed up in 2.6.0-test1, and every kernel since. The problem is that from 2.5.65 (earliest data I have) to 2.5.69 dbench on reiserfs with 16 clients got a throughput of ~200MB/sec. In 2.5.70 through 2.5.75 the score went up to ~280MB/sec, a good thing. But in 2.6.0-test1 the throughput dropped to below 50 MB/sec. Since then it has risen slightly but still at only around 60MB/sec. Single client dbench showed similar, although much less dramatic changes. No other file system exhibited a change in the 2.6.0-test1 kernel so this seems to be unique to reiserfs. Did anything change in the testing at all? Can you try again with your current software versions on 2.5.75, and reproduce the higher speeds? No, nothing changed in the test setup. Same dbench, same disk, same distro, just different kernel. Check the diffstat for the test1 release and see if there are any reiserfs changes... I believe that Oleg already said there were no changes that look like they would have caused this. More likely the behavior of something reiser is using changed which is having a bad effect on resierfs. Steve Vs discovered we are sleeping more in test0, and he is debugging the sleepometer so he can find out where (2.6.0 broke the sleepometer it seems). -- Hans
Re: dbench regression in 2.6
Mike Fedyk wrote: On Thu, Sep 04, 2003 at 09:23:42AM -0500, Steven Pratt wrote: Vladimir Saveliev wrote: Hi On Wednesday 03 September 2003 23:04, Hans Reiser wrote: Steven Pratt wrote: Is anyone looking into the dbench multitheaded regression in 2.6 that I reported here a couple of weeks ago? Sorry, I was unable to find your report in mail archives. Could you, please, remind what is the problem? I don't see any change in the latest trees. The problem showed up in 2.6.0-test1, and every kernel since. The problem is that from 2.5.65 (earliest data I have) to 2.5.69 dbench on reiserfs with 16 clients got a throughput of ~200MB/sec. In 2.5.70 through 2.5.75 the score went up to ~280MB/sec, a good thing. But in 2.6.0-test1 the throughput dropped to below 50 MB/sec. Since then it has risen slightly but still at only around 60MB/sec. Single client dbench showed similar, although much less dramatic changes. No other file system exhibited a change in the 2.6.0-test1 kernel so this seems to be unique to reiserfs. Did anything change in the testing at all? Can you try again with your current software versions on 2.5.75, and reproduce the higher speeds? No, nothing changed in the test setup. Same dbench, same disk, same distro, just different kernel. Check the diffstat for the test1 release and see if there are any reiserfs changes... I believe that Oleg already said there were no changes that look like they would have caused this. More likely the behavior of something reiser is using changed which is having a bad effect on resierfs. Steve
Re: precise characterization of ext3 atomicity
On Thu, 2003-09-04 at 18:03, Andreas Dilger wrote: > On Sep 05, 2003 01:32 +0400, Hans Reiser wrote: > > Andreas Dilger wrote: > > >It is possible to do the same with ext3, namely exporting journal_start() > > >and journal_stop() (or some interface to them) to userspace so the application > > >can start a transaction for multiple operations. We had discussed this in > > >the past, but decided not to do so because user applications can screw up in > > >so many ways, and if an application uses these interfaces it is possible to > > >deadlock the entire filesystem if the application isn't well behaved. > > > > That's why we confine it to a (finite #defined number) set of > > operations within one sys_reiser4 call. At some point we will allow > > trusted user space processes to span multiple system calls (mail server > > applicances, database appliances, etc., might find this useful). You > > might consider supporting sys_reiser4 at some point. Please rename sys_reiser4 if you want it to be a generic use syscall ;-) -chris
Re: IRC channel for reiser4 (and reiserfs)
Alex Zarochentsev writes: > On Mon, Sep 01, 2003 at 01:34:26PM +0400, Nikita Danilov wrote: > > Hello, > > > > we now have IRC channel for questions and discussion of reiser4 (and, > > occasionally, reiserfs): > > > > irc://irc.oftc.net:6667/#reiser4 > > A reference to it from namesys.com website would be good. Here: http://www.namesys.com/mailinglist.html (under "Join Mail List" button). > > -- > Alex. Nikita.
Re: IRC channel for reiser4 (and reiserfs)
On Mon, Sep 01, 2003 at 01:34:26PM +0400, Nikita Danilov wrote: > Hello, > > we now have IRC channel for questions and discussion of reiser4 (and, > occasionally, reiserfs): > > irc://irc.oftc.net:6667/#reiser4 A reference to it from namesys.com website would be good. -- Alex.
