Re: need opinions from sysadmins on where reiser4progs should install
Hello, On Sun, 20 Nov 2005 05:07:23 +0100 rvalles [EMAIL PROTECTED] wrote: | When I run make install on something and haven't specified a prefix on | configure, I expect /usr/local to be used. If I wanted /, I'd have | specified that on configure time. If it installed in / by default, it | would, often, hit the sacred package-system managed area of the VFS | tree annoying people like me to a very great extend, so please don't. While i totally agree with you for standard packages, well i based my choice on actual experience of the last past six years of use with reiserfs V3. I can't remember how many times i heard Namesys team say Install the latest greatest reiserfsck, how many times distro thought they knew reiserfsprogs internals better than Namesys and customized it to the point where it would eventually break. Of course, i can live with a manual install of reiser(fs|4)progs, so i don't really mind, but talking of support, it can make quite a difference to Namesys in terms of support, and annoyance with bug reports that could have been easily avoided. Final decision will still be Namesys call, but hopefully this whole thread gave them some valuable input to make the best decision. Thanks, Philippe
resize_reiserfs, free space in front....
Hi, i would like to grow my reserfs partition, the unsued space is in front of my root partition, between swap and root partition. as stated in the resize_reiserfs manpage: ...This can be done using cfdisk(8) for partitions, by deleting the partition and recreating it with a larger size (assuming there is free space after the partition in question). Make sure you re-create it with the same starting disk cylinder as before! Otherwise, the resize operation will certainly not work, and you may lose your entire filesystem. the same starting cylinder wouldnt change anything in my case... is it possible what i want todo with resize_reiserfs? - if yes then the manpage should be updated. greets julius
Re: resize_reiserfs, free space in front....
Reiserfs partitions, when resized; the beginning MUST stay fixed. This limitation also applies to ext2/3 filesystems. The only filesystem I know of in which the front of the filesystem can be moved is FAT; which can't be practically used for linux, IIRC. The solution is to make partitions as early on the disk as you'll ever need and put everything else at the tail end (e.g. FAT at the tail end). IIRC, LVM should also be able to manage around this; although I don't remember perfectly. On 11/20/05, julius Junghans [EMAIL PROTECTED] wrote: Hi, i would like to grow my reserfs partition, the unsued space is in front of my root partition, between swap and root partition. as stated in the resize_reiserfs manpage: ...This can be done using cfdisk(8) for partitions, by deleting the partition and recreating it with a larger size (assuming there is free space after the partition in question). Make sure you re-create it with the same starting disk cylinder as before! Otherwise, the resize operation will certainly not work, and you may lose your entire filesystem. the same starting cylinder wouldnt change anything in my case... is it possible what i want todo with resize_reiserfs? - if yes then the manpage should be updated. greets julius -- ~Mike - Just my two cents - No man is an island, and no man is unable.
Implementing an attribute directory.
We have an implementation plan for the attribute plugin. We plan to base it around the plugin.c so that it can be available for all files, directory or otherwise. Every file which has a pseudo will gain a new user-attributes pseudofile. This pseudofile will essentially wrap a standard directory. In order to provide support for this directory, this plugin will include a new field on the inode which points to a standard dir_file. When a new file is created, this inode will be created as well, and when a file is deleted, this one must be removed (with children) as well. Future versions should provide the optimization of only creating the inode once it becomes needed and otherwise simulating an empty directory. Namesys folks, does this seem like a good course of action? -pvh -- Peter van Hardenberg ([EMAIL PROTECTED]) Victoria, BC, Canada
Re: File as a directory - file-as-dir vs. link-dirs (again) - 3/3
(Apologies for email snafu - hit the wrong button.) Difference 2 can also be left aside for now. 3) Say we just used standard directories to indicate relations. Then if a user comes across these names - /(something)/father-son /(something)/father-son/aardvark /(something)/father-son/aardvark/son /(something)/father-son/aardvark/father - while browsing the filesystem she can use her common sense to guess that /(something)/father-son expresses a father-son relation. 'father-son' likely suggests a relationship between fathers and sons, and indeed /(something)/father-son/aardvark has children called father and son. Pretty obvious. Similarly, if she comes across /usr/bin /usr/bin/alpha /usr/bin/bravo [etc. etc.] , if she is familiar with Unix she will know that /usr/bin/ indicates user binaries. Every (non-directory) file in /usr/bin/ isA '/usr/bin', a user binary. (Also, common sense might suggest that /usr/bin/ has so many children that it's unlikely to be one giant relationship.) But what if she comes across /(something)/mumble /(something)/mumble/thingy/alpha /(something)/mumble/thingy/bravo ? Is alpha a '/(something)/mumble/thingy', or is it in the 'alpha' role of a '/(something)/mumble' relationship with another file? (Or it could be in the 'thingy/alpha' role of a '/(something)' relationship.) This matters a lot. The distinction between being a foo and being a party in a foo relationship is clear and important. For example, there is a big difference between being a marriage and being a married person. So we need to know which one is meant. What's more, we need to be *told*, because the other two solutions - guessing and knowing already - aren't good enough. The person who created /(something)/mumble/thingy would be able to tell us that if only she had some way of indicating to us that we should interpret /(something)/mumble/thingy as an instance of a relation. And that is (to a first approximation) all that link-directories are - directories with a simple binary flag set at creation time to indicate how they should be interpreted. Leo. -- Leo Richard Comerford - http://www.st-and.ac.uk/~lrc1 - accept no namesakes :)
Re: File as a directory - file-as-dir vs. link-dirs (again) - 3/3
On Sun, 20 Nov 2005 07:03:03 +, Leo Comerford [EMAIL PROTECTED] said: On 11/19/05, Hubert Chan [EMAIL PROTECTED] wrote: P.S. your relational model can easily be expressed using file-as-dir (well, actually, just standard directories): /(something)/father-son/aardvark/father is a symlink to '/(whatever)/portrait/Mike') /(something)/father-son/aardvark/son is a symlink to '/(whatever)/portrait/Bob') Yes absolutely. Yes, my relational model *does* uses standard directories, with three differences. 1) foofs's internal implementation of link-directories and other directories might be different. Or it might not. Entirely unimportant at this level. Yes. I think that we should distinguish between how the data is stored, and how it is exported to the filesystem. I think that anyone who tries to take a relational table, and try to translate it directly into a filesystem implementation is nuts. They are very different data models, and should not be confused. (Filesystem is probably more like an object-oriented database, or, if I remember correctly -- it's been a while since my database course, a network model database, and not like a relational model.) However, I think that it is perfectly reasonable (or at least not completely insane) to export a relational table through a filesystem interface, and have filesystem operations reflect on the underlying table. 2) gc might treat some link-directories differently to predicate-directories. (If Bob and Mike have been deleted, I don't want /(something)/father-son/aardvark/ lying around.) Yes, I think that would require some entirely different magic. (e.g. your relational model to know about primary keys and such.) 3) Say we just used standard directories to indicate relations. Then if a user comes across these names ... [...] But what if she comes across /(something)/mumble /(something)/mumble/thingy/alpha /(something)/mumble/thingy/bravo ? Is alpha a '/(something)/mumble/thingy', or is it in the 'alpha' role of a '/(something)/mumble' relationship with another file? (Or it could be in the 'thingy/alpha' role of a '/(something)' relationship.) A few points - things should not be named mumble or thingy -- things should be named descriptively (obviously -- of course, people don't always follow these obvious rules) - the user should be in charge of how he/she organizes the data, and so he/she should pick the names that he/she wants to use. It shouldn't be mandated. And anyone else who uses the data should have a reasonable expectation to have any confusing things documented. At least database schemas are usually documented for those people who need to use them. - you can still have some sort of marker to indicate what role each part of the name takes (e.g. the delimiter to indicate pseudofiles). Or you can use a special naming convention (e.g. tuples have a special prefix). But I think that trying to introduce a new delimiter that does basically the same thing as '/' is going to cause a lot of problems. (See Rob Pike's paper, The Hideous Name, if you haven't read it already, for more on this. It's cited in Hans' Future Vision paper.) As a completely different side issue, I think that using random names such as aardvark or zebra to refer to tuples is a bad idea (and I know this isn't part of your proposal). If you use things that are real words, people will get confused, since they will try to associate meaning to something that doesn't have meaning. (e.g. why is my relationship called dodo, while Bob's is called tiger?) I think that it's best to just assign random meaningless strings, so that people will know that they are meaningless. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: need opinions from sysadmins on where reiser4progs should install
Philippe Gramoullé wrote: Hello, On Sun, 20 Nov 2005 05:07:23 +0100 rvalles [EMAIL PROTECTED] wrote: | When I run make install on something and haven't specified a prefix on | configure, I expect /usr/local to be used. If I wanted /, I'd have | specified that on configure time. If it installed in / by default, it | would, often, hit the sacred package-system managed area of the VFS | tree annoying people like me to a very great extend, so please don't. While i totally agree with you for standard packages, well i based my choice on actual experience of the last past six years of use with reiserfs V3. I can't remember how many times i heard Namesys team say Install the latest greatest reiserfsck, how many times distro thought they knew reiserfsprogs internals better than Namesys and customized it to the point where it would eventually break. Of course, i can live with a manual install of reiser(fs|4)progs, so i don't really mind, but talking of support, it can make quite a difference to Namesys in terms of support, and annoyance with bug reports that could have been easily avoided. Ok, I propose the following: search the standard locations for where it is currently, tell the user, ask the user if they want to rename those versions to *.old if the install of the new one succeeds, and then prompt for the install location with /sbin as the suggested default. I think that unlike other user installed programs, fsck does not belong in /usr/local. I think Philippe's point that old versions are dangerous is quite valid. Final decision will still be Namesys call, but hopefully this whole thread gave them some valuable input to make the best decision. Thanks, Philippe
Re: need opinions from sysadmins on where reiser4progs should install
On Sun, 20 Nov 2005 23:09:01 -0800, Hans Reiser [EMAIL PROTECTED] said: Ok, I propose the following: search the standard locations for where it is currently, tell the user, ask the user if they want to rename those versions to *.old if the install of the new one succeeds, and then prompt for the install location with /sbin as the suggested default. One possible problem: if, for example, a user has reiser4progs installed as a Debian package, then the new (user-installed) version would be overwritten if the reiser4progs Debian package gets updated. Whether this is the desired result (e.g. if the new Debian package is a newer version of reiser4progs) or not (e.g. if the new Debian is just a minor bugfix on the old version of reiser4progs), I don't know. So if you choose to do this, you may want to include a warning about the above case. Users probably shouldn't try to have both the distribution-packaged reiser4progs, along with a locally-compiled version, at the same time. I think that unlike other user installed programs, fsck does not belong in /usr/local. fsck, probably not. mkfs, maybe. Another option is to default to /usr/local, to satisfy the principle of least surprise for administrators who expect all locally-compiled programs to be in /usr/local, but emit a very loud warning that this is probably not really what you want to do, and should only continue with /usr/local if you know what you are doing for the following reasons: - having old versions of reiser4progs could be dangerous - fsck will not be available until after /usr/local is mounted - /usr/local/sbin is usually not on root's $PATH - ... I think Philippe's point that old versions are dangerous is quite valid. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: Implementing an attribute directory.
Peter van Hardenberg wrote: We have an implementation plan for the attribute plugin. We plan to base it around the plugin.c so that it can be available for all files, directory or otherwise. Every file which has a pseudo will gain a new user-attributes pseudofile. This pseudofile will essentially wrap a standard directory. Usage examples please. In order to provide support for this directory, this plugin will include a new field on the inode which points to a standard dir_file. When a new file is created, this inode will be created as well, and when a file is deleted, this one must be removed (with children) as well. Future versions should provide the optimization of only creating the inode once it becomes needed and otherwise simulating an empty directory. Namesys folks, does this seem like a good course of action? -pvh
