Re: [reiserfs-list] Re: magic is useless Determining File Types
Ross Vandegrift wrote: echo requires good stereo to sound good filename/..comments Then what about the following: $ ls -aF ./ ../ somename somename_dir/ $ cp ~/file somename when I meant $ cp ~/file somename_dir/ but missed the typo? Does cp need someway to know that file isn't extended attributes? Does it just use the '..' at the beginning? Give someone a bulldozer, and they can make more mistakes with it than with a shovel. On the other hand, if I wanted to apply extended attributes to a large number of files something like: $ cp ~/..ea_set */ in a directory would be a very natural thing to attempt. But can I tell ReiserFS/VFS that ~/..ea_set doesn't actually apply to my home directory, but rather it's just a storage place for some eas I want to put elsewhere? Yes, call them ~/ea_set without the .., and user land will not think they are attributes. Obviously these issues won't come up when human error isn't involved (I could obviously call the file in ~ 'ea_set' and rename it '..ea_set' when moving it into place). But it will be frustrating for current users to learn counterintuitive limitation so GUI users can be happy. Ross Vandegrift [EMAIL PROTECTED]
Re: [reiserfs-list] Re: magic is useless Determining File Types
Miguel de Icaza wrote: Let us get a bit more specific. You should echo text/plain /etc/passwd/..mime-type Note the prepending with '..', as this allows distinguishing directory meta-data from files by use of a style convention. Folks, if you don't like .. as a prefix for meta-data, now is a good time to suggest something better. Do you need the prefix? I would love to not have the prefix (but I dont really care, what matters is to have the functionality). Why do you not want the prefix? I am easily swayed by an argument against it if I hear one. (The prefix is an optional style convention for metadata about an object, not a requirement imposed by the FS. In other words, no we don't need the prefix, but we don't know why not to use it.) Hans
[reiserfs-list] reiserfsprogs-3.x.0k.tar.gz
Hi Fresh reiserfsprogs (ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz) is now available. It became much more stable since 3.x.0j version, but any bug report is appreciated. New features: We have 5 modes now: --check consistency checking (default) --fix-fixable fix corruptions which can be fixed w/o --rebuild-tree --rebuild-sb super block checking and rebuilding if needed (require rebuild-tree afterwards) --rebuild-treeforce fsck to rebuild filesystem from scratch (takes a long time) And the last one is --clean-attributes - clean garbage in reserved fields in StatDatas on fs, which is useful only if you are going to use O-inode-attrs.patch, or just want to clean garbage from StatDatas. This option does not check/recover anything. reiserfstune - a tool to to change journal parameters for existing filesystems, allow to have non-standard journal of different size or on another device. mkreiserfs can create fs with non-standard journal. /reiserfsck/debugreiserfs changed to work with relocated journal. (do not forget that you can use reiserfs with relocated journal with journal-relocated.patch only. As the patch was not released yet, some options are still hidden) lost+found's mode is set to drwx-- after lost+found pass reiserfsck exits with 0 if there were no corruptions found, 1 if there were only corruptions fixable by --fix-fixable or 2 if --rebuild-tree is required New options: fix-non-critical became simplier and was moved to adjust-file-size option (fix file sizes to real size), can be used in fix-fixable and rebuild-tree modes. Many hidden features were added to help debugging and recovering a broken fs. Bug fixes: there were quite a few of them -- Thanks, Vitaly Fertman
[reiserfs-list] Re: When will Reiserfs be ready?
_nasturtium [EMAIL PROTECTED] writes: Besides, how can Reiser charge for support on something that other developers contributed to??? my auto mechanic charges me money for working my car. he didn't even build it in the first place support is work in and of itself. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]]
Re: [reiserfs-list] Filesystem state ERROR
Josh- IIRC, debugreiserfs reports Filesystem state ERROR if you run it on a mounted filesystem. You may want to try unmounting the partition and running debugreiserfs again. Dan I've been having some weird problems with one of our production servers where it would stop responding for a few seconds to anything. I'm not getting any weird messages in any sort of log, though. So, I finally ran debugreiserfs on the partition, and got the following.. I'm assuming the Filesystem state ERROR is bad, right? What needs to be done? Fscking it? Or is the error because of how full the volume is? Is there a way to get a more detailed reason for the error? Thanks, - Josh -debugreiserfs, 2001- reiserfsprogs 3.x.0j Super block of format 3.5 found on the 0x3 in block 16 Block count 36268744 Blocksize 4096 Free blocks 1165414 Busy blocks (skipped 16, bitmaps - 1107, journal blocks - 8193 1 super blocks, 35094013 data blocks Root block 2004734 Journal block (first) 18 Journal dev 0 Journal orig size 8192 Filesystem state ERROR Tree height 5 Hash function used to sort names: tea Objectid map size 460, max 1004 Version 0 Josh Durham, Computer Systems Engineer Aerospace Ocean Engineering at Virginia Tech Phone: 540.231.9061 Email: [EMAIL PROTECTED] * The views in this email are not representative of the views of the sender, but are a paid-for advertisment.
Re: [reiserfs-list] Intercepting all changes made to a file system on Linux
Scott Simpson [EMAIL PROTECTED] wrote on Fri, 4 Jan 2002 17:13:54 -0800: [...] Is there any way to detect if a change has been made to a file such as data changing, a change in ownership, a permissions change, etc programmatically? I looked through the various file system source code in the Linux kernel and didn't see anything that jumped out at me. Thank you. I'd be interested in hearing if there's a standard way of doing this under Linux. I've seen it in other operating systems before, Node Monitoring in later versions of AmigaDOS and Notifications in BeOS. Perhaps this relies on a message passing OS - typically you tell the OS (and file system indirectly) that you're interested in changes to a particular file or directory, and you include some flags saying what kinds of changes you are interested (iNode info, file contents, etc). Then when the file / directory changes, the file system posts a message with the details to the previously supplied message queue, which the user level program is reading from. - Alex
Re: [reiserfs-list] Intercepting all changes made to a file system on Linux
On Fre, 04 Jan 2002, Scott Simpson wrote: there any way to detect if a change has been made to a file such as data changing, a change in ownership, a permissions change, etc programmatically? I looked through the various file system source code in the Linux kernel and didn't see anything that jumped out at me. Thank You want the linux directory notification (see documentation in linux source tree). Its not very advanced and not very relieable, but is the best thing Linux provides. Dirk
[reiserfs-list] First there were Files, then Attributes, then XML Storage and in the Far Future - Objects
Philipp Gühring [EMAIL PROTECTED] wrote on Sat, 5 Jan 2002 03:35:23 +0100: Then I would suggest using XML instead, (perhaps a special form of it). That would give the needed flexibility. He also wrote in another message: I looked at MacOS and other ideas of attaching metadata to data, but I only found one real solution. Get the metadata inside. Use one structured Fileformat, that includes all the needed Metadata. For example XML. [...] Then we could represent the whole disk volume as one big XML file, and directory operations would become traversals of subchunks of the XML? It's just using XML to get the functionality of a file system. But under the hood, inserting and deleting things in the XML blob corresponds to inserting and deleting files from a file system. H. You may be on to something here. Let me expand on your idea and take it to the next level... The XML Object File System! I can see that the next-next generation file system will be dealing purely with objects. Kind of a object database. Besides representing an object (which would be equivalent to today's files plus attributes - the type info specifies which programs (methods) can process it), you'd also want to represent objects being inside objects, and represent object references (what you now know as pointers, symbolic links, hard links, etc). Plus it's lots more fun if you have a way of finding objects other than doing name space hierarchy traversals - the indexing system or database aspect. You could conceptually do all this with a big XML file. Object references would be serial numbers (GUIDs, inodes, URLs etc). It should allow cycles in the connection-by-reference graph. Containing objects work with the usual nested XML hierarchy technique, no cycles allowed. Actual object data is stored via the usual XML tags to identify field names and corresponding values. Keep the same high level concept, but turn it into a file system. If you copy the root node's XML view of its contents you get the big XML blob. Could make backups easier too - copy the big XML stuff to the root node's XML virtual attribute to restore your file system. Under the hood, subobjects become subdirectories or subfiles in the root object. Yup, looks like you have to treat everything as both a file and a directory. The key/value tags become attributes. References to other objects become links. One design decision is how to implement the equivalent of directories - whether to list subobjects as attributes of type hard link and have an attribute/link pair (file name is the attribute name, value is an object reference) for each item (a directory listing would be generated by iterating through all attributes and printing out the ones of type link). Or to have an attribute which is of type dictionary of links that contains an array of name/link pairs in sorted order (or unsorted?). I'd mash them all together into one pool of attributes to save on redundant code. Finally, there's the indexing service. Attributes with names of interest (not everything needs to be indexed) are added to the root's indices. Perhaps as Hans suggested, these could be magic directories that contain all things that have that attribute, the names being the attribute values and the values being links to the objects. This implies sorted directories are needed. As new objects get created, they also get magically added to the relevant index directories. Automagically update the index directories for renames, deletions and attribute value changes. For searching the index directories, you could either have a standard library which will parse your query string and search the indices for you, or you could have it built into the file system. Built-in permits you to do live update notification when new objects that match a query appear or disappear. Alternatively, if change notification is implemented then the query library could monitor the index directories of interest for changes. Hmmm. Change notification from the index directories and an external query library would let you more easily change your query language to whatever you like. Well. Sounds like another file system project for me to experiment with, after I've finished my BeOS RAM file system first! - Alex
Re: [reiserfs-list] Re: magic is useless Determining File Types
Hans Reiser [EMAIL PROTECTED] wrote on Sat, 05 Jan 2002 02:52:56 +0300: I think that with reiser4, we just need to settle on a style convention (what is it called, ..content-type or ..mime-type or ..type or.?) Do we need to write a plugin for it? I think maybe not, I am not sure the filesystem ever does anything with the attribute, it is purely a user space affecting attribute. If you're doing indexing, then the file system does need to update its index directories with the current value of the attribute and the pointer to the file. But it would need to do that with all attributes that are being indexed. - Alex
Re: [reiserfs-list] First there were Files, then Attributes, then XML Storage and in the Far Future - Objects
After a bit of thought, I've got a few more points about The XML Object File System idea. Minor point - the data of a file/object would be stored in an attribute named default-data or data or maybe even (that's the one old software gets when you don't specify an attribute when opening an object). You'd get a file handle to an attribute to be able to read and write its value. When all handles to an attribute are closed, the index gets updated with the new value (if it's an indexed attribute). Possibly it would have to be removed from the index when the handle is opened (otherwise you'd have to keep around a copy of the old attribute value to know what to delete from the index). Hans Reiser [EMAIL PROTECTED] wrote on Sat, 05 Jan 2002 03:44:22 +0300: Miguel, do you agree that if and only if one makes directories and files functional enough, then it becomes a cleaner design to have just files and directories? and other people also commented on liking just files and directories. I can see how the object system could be expressed as just files and directories: * Each object becomes a directory. The name is the object's name, probably use the Human readable one to make manual hacking easier. * An object inside another object becomes a subdirectory. * Each attribute becomes a file in the object directory, name being the attribute name and contents being the value of the attribute. Still, you need an extra type encoding somewhere to say that the attribute is a string, or number, or link reference or other simple type. Encode the primitive type as the first byte in the contents if there's no better way. * There needs to be a global directory of all objects, for finding a particular object when given the ObjectID. It has the unique ObjectID as the name and the link points to the object directory. Either symbolic links or hard links could be used. Another way would be needed for finding remote objects, perhaps URLs instead of ObjectIDs? * The index directories work similarly. For indexed attribute named X, there is a global index directory named X which contains an entry named with the attribute's value and pointing to the object directory that contains the attribute. The index directory has to allow multiple entries with the same name (since several objects could have attributes with the same value). * Notification of changes to files/directories get mapped to notification of changes to objects. The next question is then should the objects be done as part of the file system level or as a new object system level? I think it would be easier to write the object level initially as a system library and have new software go through it instead of the normal file system API. Or have it as a file system with extra ioctl operations for the new features, that way old code works with the default-data attribute. When viewing an existing old style file system through the object system, old style items show up as fake object - /etc is an object of type object-container with attribute fstab having a value of simple-type binary with whatever's in that file. If they add an icon to /etc, a new file called Icon appears with the icon data as its contents (or maybe an Icon object is used which contains several different graphic objects, one for each resolution - the icon is then a directory containing a subdirectory Icon32.png which contains the PNG image in a file called default-data and has more files such as width containing 32 as a 4 byte binary number). Locking objects? Corresponds to locking directories. Locking attributes corresponds to locking files. A handle to the object corresponds to a handle to the object directory. The object system will probably use its own handles, but include the corresponding file system handle inside. Change notification? The underlying simple file system notifies the object system of changes to the attributes (attribute file changed) or addition of new attributes (object directory changed) or changes to the index (index directory changed). The object system would probably also update the index directory and global ObjectID directory rather than having the file system do it. Networking? Either share at the file system level or share at the object system level? If file system notifications work across the network, and locking works too, then you should be able to get by with just sharing at the file system level. Indexing queries? The object system just searches through the index directories. Live queries are handled by monitoring change notification messages from the index directories (added/removed objects are run through the user's query filter and if they match, an object added/removed notification is sent to the user). A file system which could support lots of small files (most of them with the same file name too) would be ideal. Wonder where you can get one of those :-). But it still needs change notification, and
[reiserfs-list] What is Object Oriented Balancing? Seeking primer:
Can anyone point me to some sort of primer on the concepts of Object Oriented Balancing? Hans, et. al., have mentioned the OO balancing code in the FS and I'd like to understand what that is all about... get some context. Thank you. -- Sean
Re: [reiserfs-list] magic is useless Determining File Types
From: Hans Reiser [EMAIL PROTECTED] Jens Benecke wrote: User space: There should be a way of specifying what default MIME type a file should get and whether the MIME type should follow the extension (if it has one). One thing I didn't like in OS/2 was that sometimes it was really difficult to persuade the WPS to open a specific file with another viewer by default (eg. hex viewer). Changing the extension didn't help and the EAs weren't editable without extra tools. I think this is the most important thing, that one should be able to cast a file into a different type. Then one also needs to be able to convince app writers to try to make their apps work on the most generic type possible, which is difficult to do but probably we will have to endure failure at this in return for the benefits of typing and the object orientation it allows. I think that at this point we just need to focus on completing version 4, and it is good to know that people will use its features once they are available. We are indeed going to give you the flexibility you need to create whatever file/attributes or file/forks you need, though we will make do this by making files and directories able to do what you want attributes and resource forks able to do (this is nontrivial). Yes, once everybody supports it, it will no longer be an issue, however what should you get when you open the various resources? You need to be able to get *everything* for programs such as tar and cp, but then you've got ordinary programs that just want their data. My tendancy is that the prior suggestion of the structured file is the way to go. Open file and you get *everything*, open file/data and you get only the data. ..content-type turns out to be something that needs no specific support in version 4, the generic mechanisms will be enough for it. Suggestions for alternatives to .. as the style convention for meta-data about an object are welcome. May I suggest // instead? This is much better for a couple reasons. First / by itself is already a magic character, and so this doesn't annoy people by stopping them from creating files with certain names; same for programs. Second this is usable on directories, ie a file bar inside a directory foo (foo/bar) is distinct from an attribute bar on the directory (foo//bar). There is an issue of going completly overboard, attribute/subattribute/subsubattribute anybody? This is certainly an overall interesting idea. How about file//acl for accessing ACLs? This does mean though you *MUST* have a filesystem specific dump tool. -- |\__/|\__/|\__ --= 8-) EHM =-- __/|\__/|\__/| \|| | [EMAIL PROTECTED] PGP 8881EF59 | ||/ \ \ | __| -O #include stddisclaimer.h O- |__ | / / \___\_|/82 04 A1 3C C7 B1 37 2A E3 6E 84 DA 97 4C 40 E6\|_/___/
Re: [reiserfs-list] Re: magic is useless Determining File Types
On Sun, Jan 06, 2002 at 12:39:05AM +0100, Jens Benecke wrote: I don't know if there are any (printable) characters that are NOT allowed in Unix file names yet but if there are, use those. They are '/' and '\0' Anyhoo the following needs to be pointed out. 1) I question the need for metadata capabilities to end up in ReiserFS (or ext2, or ext3) at this time. 2) I see a lack of consensus about what sort of metadata should be grafted onto files, yet I already see questionable arbitrary limits appearing. Perhaps some of the advocates could make references to userspace rich file format APIs that provide the functionality you seek. [1] 3) Given some APIs, perhaps a common API wrapper that the average coder could be encouraged to use correctly and manages to work on common desktop and server operating systems. 4) Given an API, create a usermode filesystem that makes the extensions transparent[2] to programs that don't use the API and work out the interface issues. 5) Once the usermode filesystem has reached a point where it doesn't give Al Viro nightmares, start moving the new functionality to the common VFS layer. 6) Once the extensions are in the VFS layer, consider tweaking existing filesystems to handle the extensions more efficiently. 7) All of this appears to be an attempt to graft the behavior of a single level store operating system (Like OS/400 or Mungi) onto the Unix model. I wonder if it would not be more efficient to adapt a single level store system to desktop use, now that they ship with POSIX subsystems. [1] I would like to thank the person that mentioned XML although that's a bit later than the API :-). [2] Then again, I would rather see rich file that can be manipulated by command line file and directory manipulation tools flagged as a filetype other than file or directory, so much for transparent. -- Chris Dukes Bert is apparently VIL, whereas Oscar is just a sysadmin^Wgrouch. -- gorski
Re: [reiserfs-list] magic is useless Determining File Types
On Sat, Jan 05, 2002 at 04:26:21PM -0800, The Amazing Dragon wrote: May I suggest // instead? This is much better for a couple reasons. First / by itself is already a magic character, and so this doesn't annoy people by stopping them from creating files with certain names; same for programs. Second this is usable on directories, ie a file bar inside a directory foo (foo/bar) is distinct from an attribute bar on the directory (foo//bar). So that 'mv /mp3dir/* //newmp3dir' will add my MP3s as attributes to '/'? sarcasm I LOVE IT! /sarcasm I would rather see a useful rich file format API, and a userspace filesystem implementation before I see that kind of dinking on reiserfs. I get enough joy from coders neglecting to quote filenames in shell scripts as it is. I'm afraid that sanity checking the file before tacking on the path to the attributes is beyond their abilities. -- Chris Dukes Bert is apparently VIL, whereas Oscar is just a sysadmin^Wgrouch. -- gorski
[reiserfs-list] reisrer on root...
Hi... I have used reiser in the past, but this is the first time I've shifted all partitions over to reiser, including root... My question is whether I should put read-only or read-write as an option in lilo? reiser gave a warning about read-only afer a recent power failure. tim -- - Tim Therese Fairchild Atchafalaya Border Collies. Kuttabul, Queensland, Australia. - Email mailto:[EMAIL PROTECTED] Homepagehttp://www.bcs4me.com -
