Re: reiser4 plugins
On Mon, 27 Jun 2005 13:25:14 CDT, David Masover said: I was just trying to avoid the people will never adopt a new archive format argument by pointing out that a similar archive format was recently created and adopted. Out of curiosity, adopted by popular acclaim, or because an 800 pound gorilla said This is the format we're shipping XYZ in, learn to deal with it? (I've seen both happen multiple times in the last quarter century, on many different operating systems) (For that matter, all of my production boxes are backed up by either Tivoli or Legato, and I haven't a *clue* what format those tapes are in. As a practical matter, it doesn't really matter - after the first quarter petabyte or so of backed up data, you're not going to do a restore without the software's help anyhow.. ;) pgpG4HKmqmFUb.pgp Description: PGP signature
Re: reiser4 merging action list
Hello On Tue, 2005-06-28 at 06:58, Andi Kleen wrote: Hans Reiser [EMAIL PROTECTED] writes: * metafiles should be disabled until we can present code that works right. Half the list thinks we cannot solve the cycles problem ever. Disable metafiles and postpone problem until working code, or the failure to produce it, makes it possible to do more than rant at each other. This is currently already done in the -mm patches, but is mentioned lest someone think it forgotten. * update the locking documentation Probably I forget something. These are all big picture issues, but I think some low level attention to the individual code is still needed. Some stuff that stood out from a very quick look: I would like for the custom spin lock debugging (spin_macros.h) and profiling code to be removed (prof.[ch], spinprof.[ch]). Such code shouldn't be in specific subsystems. sorry, Andi, I guess you are looking at something old. Reiser4 does not have neither prof.[ch], nor spinprof.[ch] and we removed already some debugging code from spin_macros.h. The division functions in lib.h are useless IMHO, both callers seem to use divide by a power of two. And gcc supports shift in 64bit fine in the kernel. Can you remove that please? ok statcnt.h: This is completely useless because you don't align the individual fields for cache lines - so you will still have false sharing everywhere. Also using NR_CPUS is nasty because it can be very big - num_possible_cpus() is better. It should use the new dynamic per cpu allocator. statcnt.h is already removed. Best you just remove it for now and use atomic_t and readd properly when you do real SMP tuning with measurements. debug.[ch]: A lot of these functions like schedulable are name space space polluting. reiser4_kmalloc() such wrappers are deprecated. Please remove. ok xmemset et.al should be replaced with the normal functions everywhere done. Best would be probably to remove most of these files for submission. What is reiser4_internal? Can't you just use static like everybody else? ok status_flags.c: Please remove that CONFIG_FRAME_POINTER code. In general i think it would be better if you removed that private mini crashdumping. ok Is there any reason you can't just use wait queues like everybody else instead of these reimplemented condition variables in kcond.[ch]? I will investigate that In general it would be good if someone experienced not from the reiser team would read the whole source and looks for obvious problems (I didn't, just mentioning stuff I from a quick look at some support files) -Andi
Re: reiser4 plugins
On Tuesday 28 June 2005 01:07, David Masover wrote: Vitaly Fertman wrote: On Friday 24 June 2005 23:46, Hans Reiser wrote: David Masover wrote: I was able to recover from bad blocks, though of course no Reiser that I know of has had bad block relocation built in... there was a patch somewhere. Vitaly, please comment. http://www.namesys.com/bad-block-handling.html describes how reiserfs handles bad blocks. Anything like this for v4? in todo for v4, not implemented yet. -- Thanks, Vitaly Fertman
Re: reiser4 merging action list
On Tue, Jun 28, 2005 at 12:37:11PM +0400, Vladimir Saveliev wrote: have neither prof.[ch], nor spinprof.[ch] and we removed already some debugging code from spin_macros.h. Yes, i was looking at some older tree with reiser4. Sorry, just ignore what is already done. But still spin_macros.h should be completely removed imho. Such custom lock wrappers are strongly discouraged because it makes it hard for others to read your code. statcnt.h: This is completely useless because you don't align the individual fields for cache lines - so you will still have false sharing everywhere. Also using NR_CPUS is nasty because it can be very big - num_possible_cpus() is better. It should use the new dynamic per cpu allocator. statcnt.h is already removed. Great. -Andi
Re: reiser4 merging action list
Andi Kleen wrote: Yes, i was looking at some older tree with reiser4. Sorry, just ignore what is already done. But still spin_macros.h should be completely removed imho. Such custom lock wrappers are strongly discouraged because it makes it hard for others to read your code. I may comfirm that this makes Reiser4 very difficult to investigate. Ctags doesn't work with that too.. -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia.
dmapi support for reiser4
Hi, DMAPI support is a feature which is essential for usage in many important environments. Are there any plans to add dmapi support to reiser4 ? Bjoern
Re: reiser4 merging action list
On Mon, Jun 27, 2005 at 04:00:01PM -0700, Hans Reiser wrote: Andrew asked me to put together a list of things that need to be done before merging: ... Probably I forget something. I've started to do a very basic look over the tree and there's a few more things that spring to mind: - cpp abuse. There's quite a lot of really odd macros - the typesafe_list, typesafe_hash stuff is mentioned already, but there's really horrible stuff like _INIT_ and _DONE_ bits in init_super.c, and the wrappers for plugin method invocations. - endianess handling. The d* types are a lovely attempt to make sure you're not missing endianess conversions. We have a more general way to ensure that now using sparse, that's the __le* / __be* types. Try running sparse -Wbitwise to find places you'll need that annotations (after the normal sparse warnings are fixed, else you'll have a hard time seeing them I guess) - after that the single element struct thing can go away. Also you're defining a CPU_IN_DISK_ORDER macro that's never used.. - lease use kthread_* instead of kernel_thread() + lots of opencoding
Re: reiser4 merging action list
On Mon, Jun 27, 2005 at 04:00:01PM -0700, Hans Reiser wrote: Andrew asked me to put together a list of things that need to be done before merging: ... Probably I forget something. * remove the dependency on !4KSTACKS Best, Hans cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: reiser4 plugins
On Friday 24 June 2005 03:57, Hans Reiser wrote: One, you were using V3 not V4. Two, this bug you mention is probably not an fs bug. rm first creates a list of names, and then removes them. shell creates a list of names, rm simply handles the given set of names and tries to remove a file twice if specified twice. the problem could be in the shell, or what is more likely in patterns that overlap each other, like in the example of 'rm *fu fi*'. we should probably investigate a reproducable example. [EMAIL PROTECTED]:~/scratch touch fufu [EMAIL PROTECTED]:~/scratch touch fifu [EMAIL PROTECTED]:~/scratch rm *fu fi* rm: cannot remove `fifu': No such file or directory Your file either somehow got removed before rm got to it, or rm somehow got to it twice. Vitaly, can you look at the error handling by rm and see if it can get to things twice when it hits an error or if you can once per every given name. otherwise figure this out? If I remember right, I have hit this myself for non-reiserfs filesystems, and I never investigated it. Michael Dreher wrote: Not everyone will want to reformat at once, but as the reiser4 code matures and proves itself (even more than it already has), I for one have seen mainly people with wild claims that it will make their machines much faster, and coming back later asking how they can recover their thrashed partitions... Then please show us some Links/Message-IDs to such postings. I'd like to read them. Here you are The following happened to me with reiserfs as it was shipped with suse 9.1: -- [EMAIL PROTECTED]:~/mytex/konstanz/wohnung ls auto makler2.aux makler2.log makler2.tex makler.aux makler.log swk.eps unilogo.eps briefkpf.tex makler2.dvi makler2.ps makler3.tex makler.dvi makler.tex unikopf.tex [EMAIL PROTECTED]:~/mytex/konstanz/wohnung rm *.aux *.log rm: cannot remove `makler2.log': No such file or directory [EMAIL PROTECTED]:~/mytex/konstanz/wohnung ls auto briefkpf.tex makler2.dvi makler2.ps makler2.tex makler3.tex makler.dvi makler.tex swk.eps unikopf.tex unilogo.eps [EMAIL PROTECTED]:~/mytex/konstanz/wohnung uname -a Linux euler03 2.6.5-7.108-smp #1 SMP Wed Aug 25 13:34:40 UTC 2004 i686 i686 i386 GNU/Linux [EMAIL PROTECTED]:~/mytex/konstanz/wohnung date Tue Sep 21 13:15:45 CEST 2004 -- Note the line rm: cannot remove `makler2.log': No such file or directory There was no data loss, but such a bug should not happen. I never had similar experiences with ext3. Unfortunately, I cannot reproduce this behavior. Powerloss, unpluging the Disk while writing, full filesystem, heavy use : No problems with reiser4.. It *is* stable. My impression: reiser3 is not 100% stable, but quite stable, written by someone who asks for review by benchmark. Michael -- Thanks, Vitaly Fertman
Re: dmapi support for reiser4
Hello On Tue, 2005-06-28 at 13:34, Bjoern JACKE wrote: Hi, DMAPI support is a feature which is essential for usage in many important environments. Are there any plans to add dmapi support to reiser4 ? there is no currently Bjoern
cryptocompress [was Re: reiser4 plugins]
Hi! and vfat people may decide they want cryptocompress, I'm sure they don't, because it is mostly for Windows and assorted devices (pendrives, digital cameras, ...) compatibility. Actually cryptocompress for vfat *would* be nice; pen drives are small, slow, and likely to be lost/stolen. That makes them very nice candidates for cryptocompress ;-). Pavel -- teflon -- maybe it is a trademark, but it should not be.
GET latest softwares, 99% savings.
Looking for cheap high-quality software? http://edrd.holekgzaerzow0h.hoggishlymi.com Are you insinuating that I am a purveyor of terminological inexactitudes? Nothing is worth doing unless the consequences may be serious.
How to user reiser4 and crypt plugin ??
Hello, I have read so much about reiser4 and the crypto plugin. What I have not found is any docs on how to set up a partition using the plugin. I have the modules installed and I have created a reiser4 filesystem. I am not sure what I need to do next. Thanks from a reiser newbie, Keven Murphy [EMAIL PROTECTED] Murphy's Law ((U+C+I)x(10-S))/20xAx1/(1-sin(F/10)) U = UrgencyC = Complexity I = Importance S = Skill F = Frequency A = Aggravation This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
Re: reiser4 plugins
Markus Törnqvist [EMAIL PROTECTED] wrote: On Thu, Jun 23, 2005 at 11:34:50PM -0400, Horst von Brand wrote: David Masover [EMAIL PROTECTED] wrote: I think Hans (or someone) decided that when hardware stops working, it's not the job of the FS to compensate, it's the job of lower layers, or better, the job of the admin to replace the disk and restore from backups. Handling other people's data this way is just reckless irresponsibility. Sure, you can get high performance if you just forego some of your basic responsibilities. Your honest-to-bog opinion is that the FS vendor is responsible for the admin not taking backups or the hardware vendor shipping crap? No. But just relying on perfect hardware and concientious sysadmins is reckless. Hardware /is/ flaky, sysadmins /are/ (sometimes) lazy (and besides, today they are increasingly just plain Joe Sixpack users). Also, backing up a few hundred GiB is /not/ fun, and then keeping track of all the backups is messy. Also, I'm not claiming that they are /solely/ responsible, but not having the filesystem fall apart utterly every time some bug breaths on it /is/ a requirement. *still trying to understand how that can be* You haven't been around too much yet, do you? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Re: reiser4 plugins
Alexander Zarochentsev [EMAIL PROTECTED] wrote: On Sunday 26 June 2005 21:02, Christoph Hellwig wrote: [...] David and Hans, I've read through my backlog a lot now, and I must say it's pretty pointless - you're discussing lots of highlevel what if and don't actually care about something as boring as actual technical details. Hans has lots of very skillfull technical people like zam and vs, and maybe he should give them some freedom to sort out technical issues for a basic reiser4 merge, and one that is done we can turn back to discussion of advanced features and their implementation, hopefully with a few more arguments on both sides and a real technical discussion. Unfortunately, this is not only a technical discussion... it is about linux development model too. Then better separate the two, keeping the technical discussion on LKML and taking the development model stuff elsewhere. Well, about the plugins. First step: Axe them. They are (at most) /configuration options/, that will have to get fixed meanings, available to all ReiserFS filesystems purely for compatibility reasons. Sure, do get wild on new options in your own experimental trees, and migrate what survives into the standard version (and then it'll be ReiserFS 4.1, 4.2, ..., 4.25, ...). We can clean reiser4-VFS interface up by setting per-vfs-object inode/dentry/super ops instead using of our own dispatcher. Sounds reasonable. So different reiser4 inodes/files will have different i_ops/f_ops. That would be only visible-in-VFS part of reiser4 object plugins. How would that work out from the userland (system call) perspective? How does that get handled from on-disk format? Would the help to solve reiser4 plugins question? It is just as other FS do -- procfs has seq_file and sysconfig interfaces below the VFS and l-k people do not complain each day about layering violation ;-) Procfs is taken as an example because it deals with objects of different types, actually anybody may create own procfs objects more or less general way. But procfs /is/ quite special, as it is supposed to be a window into the kernel, not real files. Some layering violation is unavoidable there. I don't belive that you want to see all reiser4-specific things as item plugins, disk format plugins in the VFS. Only what makes sense. Plus many of those will probably have to go. Decide on /one/ way of doing things, even if not perfect for all uses. Everything else is useless bloat. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Re: How to user reiser4 and crypt plugin ??
Keven Murphy wrote: Hello, I have read so much about reiser4 and the crypto plugin. What I have not found is any docs on how to set up a partition using the plugin. Hello. Crypto transform is unsupported for a while, only compression (still not for product using). The docs are under construction. Thanks, Edward. I have the modules installed and I have created a reiser4 filesystem. I am not sure what I need to do next. Thanks from a reiser newbie, Keven Murphy [EMAIL PROTECTED] Murphy's Law ((U+C+I)x(10-S))/20xAx1/(1-sin(F/10)) U = UrgencyC = Complexity I = Importance S = Skill F = Frequency A = Aggravation This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
Re: How to user reiser4 and crypt plugin ??
Thank you for the reply. Do you see any issues with using reiser3 or reiser4 file system on a loop-back encrypted device? Some of the docs I have found say to stick with ext2 for the filesystem. I was thinking reiser still would be a better choice. Thank you for your help, Keven Murphy [EMAIL PROTECTED] Murphy's Law ((U+C+I)x(10-S))/20xAx1/(1-sin(F/10)) U = UrgencyC = Complexity I = Importance S = Skill F = Frequency A = Aggravation On Tue, 28 Jun 2005, Edward Shishkin wrote: Keven Murphy wrote: Hello, I have read so much about reiser4 and the crypto plugin. What I have not found is any docs on how to set up a partition using the plugin. Hello. Crypto transform is unsupported for a while, only compression (still not for product using). The docs are under construction. Thanks, Edward. I have the modules installed and I have created a reiser4 filesystem. I am not sure what I need to do next. Thanks from a reiser newbie, Keven Murphy [EMAIL PROTECTED] Murphy's Law ((U+C+I)x(10-S))/20xAx1/(1-sin(F/10)) U = UrgencyC = Complexity I = Importance S = Skill F = Frequency A = Aggravation This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
Re: How to user reiser4 and crypt plugin ??
Keven Murphy wrote: Thank you for the reply. Do you see any issues with using reiser3 or reiser4 file system on a loop-back encrypted device? No, it works for both ones. Use the last patchsets for reiser4, report if something is wrong. Thanks, Edward. Some of the docs I have found say to stick with ext2 for the filesystem. I was thinking reiser still would be a better choice. Thank you for your help, Keven Murphy [EMAIL PROTECTED] Murphy's Law ((U+C+I)x(10-S))/20xAx1/(1-sin(F/10)) U = UrgencyC = Complexity I = Importance S = Skill F = Frequency A = Aggravation On Tue, 28 Jun 2005, Edward Shishkin wrote: Keven Murphy wrote: Hello, I have read so much about reiser4 and the crypto plugin. What I have not found is any docs on how to set up a partition using the plugin. Hello. Crypto transform is unsupported for a while, only compression (still not for product using). The docs are under construction. Thanks, Edward. I have the modules installed and I have created a reiser4 filesystem. I am not sure what I need to do next. Thanks from a reiser newbie, Keven Murphy [EMAIL PROTECTED] Murphy's Law ((U+C+I)x(10-S))/20xAx1/(1-sin(F/10)) U = UrgencyC = Complexity I = Importance S = Skill F = Frequency A = Aggravation This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
README clobbered
The README at ftp://ftp.namesys.com/pub/reiser4-for-2.6/ was modified today. When I tried to check the changes, I noticed that the file is empty. -- Jake Maciejewski [EMAIL PROTECTED]
Re: README clobbered
Hello On Tue, 2005-06-28 at 20:42, Jake Maciejewski wrote: The README at ftp://ftp.namesys.com/pub/reiser4-for-2.6/ was modified today. When I tried to check the changes, I noticed that the file is empty. thanks for noticing that, I guess someone did that mistakenly, should be fixed now
Re: reiser4 plugins
On Tue, 28 Jun 2005 02:01:12 -0400, Kyle Moffett [EMAIL PROTECTED] said: On Jun 28, 2005, at 01:30:08, Hubert Chan wrote: On Tue, 28 Jun 2005 00:38:38 -0400, Kyle Moffett [EMAIL PROTECTED] said: Ok. Those things should probably be divided up. Stuff like POSIX extended attributes and such that have existing interfaces should use those. One of the claimed advantages of the '...' interface is that everything is editable as a file. So if someone wanted to edit the description extended attribute for foo.txt, he would just run [editor] foo.txt/.../description (or [editor] /meta/fs/$(getattrpath foo.txt)/description), instead of needing to use some special purpose editor. It works well for things like being able to use Gimp to edit a thumbnail or icon attribute. I don't disagree with the thumbnail/icon/description, but things like POSIX acls and extended attributes have _existing_ interfaces which should be used. OK. I agree with that. Of course, Reiser4 can always present both interfaces, just like it presented two interfaces to the stat data -- the regular interface and the metas (now '...') interface -- before file-as-dir got disabled by default. I don't deny them the right to add other interfaces later, but such should be a secondary or tertiary patch, after the rest of the stuff is in. In any case, if we were to provide an interface by which one could $EDITOR the POSIX ACLs, it should be done in the VFS where all filesystems can share it. I don't know if VFS is the right place for it, but I agree that it would be good to make it accessible to all filesystems. The inspiration, I think, was the MacOS X/NeXTSTEP bundle format. For example, MacOS X/NeXTSTEP .app file is actually a directory that behaves much like an executable file (double-clicking a .app file in the Finder launches the application, instead of opening the directory). However, it is in reality a directory that contains many things that could be thought of as extended attributes (such as the application icon, information about the application, etc.). Since the application icon is a real file, it can be edited by normal graphics editors (not like Windows programs, where you need a special icon editor). And since it's inside the .app directory, it's attached to the application (not like Linux, where the program is in /usr/bin, and the icon is in /usr/share/pixmaps), so it makes package management easier (to delete an application, just delete the .app file -- don't need to look in /usr/share/pixmaps for the icon and delete it). The key difference here is that Mac OS X does all of the bundle mess in userspace where it belongs. :-D (I know, I use it daily) Yes. It's handled by NSWorkspace which is approximately equivalent to this sort of thing being handled by GnomeVFS or the KDE equivalent. Of course the problem with handling it in userspace is that behaviour isn't uniform -- applications that don't use NSWorkspace (e.g. some command-line utils, programs ported over from UNIX, etc.) won't have the same behaviour. Whether or not that is an actual problem seems to be debatable. (I don't use MacOS X, but I've done some programming in GNUstep.) Another problem is that it only works with bundle files. e.g. I can't add an icon to a regular txt file. Tiger now supports xattrs, which you could use for that functionality, but then we run into the problem again of not being able to edit it with regular applications. I think that part of Reiser4 needs more review than it's been given at present. Looking forward to the flamewar that happens when Namesys decides that file-as-dir is ready to be turned on again. ;-) -- 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: How to user reiser4 and crypt plugin ??
On Tue, 28 Jun 2005 11:38:30 -0400 (EDT), Keven Murphy [EMAIL PROTECTED] said: Thank you for the reply. Do you see any issues with using reiser3 or reiser4 file system on a loop-back encrypted device? I'm using reiser4 on a loopback encrypted device without problems. (But then, I haven't had any hardware problems or powerlosses.) Some of the docs I have found say to stick with ext2 for the filesystem. I was thinking reiser still would be a better choice. From what I hear, you should avoid using journaled filesystems on a file-based loopback that is stored on a journaled filesystem. I believe that the reason for that is that a file-based loopback that is stored on a journaled filesystem does not guarantee certain write ordering or that journaled filesystems depend on. But using a journaled filesystem on a device-based loopback should be fine. -- 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: reiser4 plugins
On Tue, June 28, 2005 10:01 am, Horst von Brand said: I don't belive that you want to see all reiser4-specific things as item plugins, disk format plugins in the VFS. Only what makes sense. Plus many of those will probably have to go. Decide on /one/ way of doing things, even if not perfect for all uses. Everything else is useless bloat. It doesn't seem to be a problem as long as loadable plugins are GPL. How is it useless bloat? It doesn't seem much different from having loadable modules in the security system. Just don't enable Reiser4 in your kernel if you don't want to use it. Sean
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vitaly Fertman wrote: On Tuesday 28 June 2005 01:07, David Masover wrote: Vitaly Fertman wrote: On Friday 24 June 2005 23:46, Hans Reiser wrote: David Masover wrote: I was able to recover from bad blocks, though of course no Reiser that I know of has had bad block relocation built in... there was a patch somewhere. Vitaly, please comment. http://www.namesys.com/bad-block-handling.html describes how reiserfs handles bad blocks. Anything like this for v4? in todo for v4, not implemented yet. Is it significantly different that there'd be another doc I can read? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQsGhjXgHNmZLgCUhAQJaeg/7BeQVRKc0m0AEKiwp6B/N/R6/32JcIvk9 0jZq3A6wYsSxmRSDfId+FVoHApAoZldOtw5CZ7W3TwUJBxzGwFZ7IYM4mQaZ5eRa 7CdAoX9LrG85sY/2M9qypE5cW6BQ/0DJFPDOiree/+6mNomg8uOUJ6FeO93j2JW3 jdPrWqsmYBPSDo4vKha+xoAZpCH/sMLwDDBUIFfC2iz4B4yTxYNfEX+mJ4T2mEls 3YqSiTMkgnFbsVTdUiIjqVJY+jJ9ALhDKdc/hkNNrNir3Iib6aNbg9J9J5cDgNHU zzvNyp6WsCgQjtCvfMojVewKAMu94eg1sXt6ESNz4dKbdPBSdo+lBnATntnMjFCN 7nS9K/kKcTKwSVQjQdyEhbm51C9SXYLxj4CMcru9ZyVtdlyzCLhBda1FvaxWbatJ iGCh8tg43Xkd1N4H+LlTQpJrfbkJBXu4U9oYIuNSQuolMfz6IbJqcfNzV0hm9drp lGLODFSFEWFqHUgPqLymk8/pBW9xP4XYwwWFcY8x0Dw4UxpWRB43EZ8Nydg4PBEk SrLnq1FNSP+QLHZvWwF+8vpWj1jyeiBU2hFpt/p9crU5uy4OWGbKEh8GuEHFgp9P BdKzp4iwTFwgjKR/uM3JnCfN4ct0yyyBZVMNf0N8w2Idu4OkBiS2edg/70A8/OqV U0JVANH5qxc= =sd/Q -END PGP SIGNATURE-
Re: How to user reiser4 and crypt plugin ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hubert Chan wrote: On Tue, 28 Jun 2005 11:38:30 -0400 (EDT), Keven Murphy [EMAIL PROTECTED] said: Thank you for the reply. Do you see any issues with using reiser3 or reiser4 file system on a loop-back encrypted device? I'm using reiser4 on a loopback encrypted device without problems. (But then, I haven't had any hardware problems or powerlosses.) Some of the docs I have found say to stick with ext2 for the filesystem. I was thinking reiser still would be a better choice. From what I hear, you should avoid using journaled filesystems on a file-based loopback that is stored on a journaled filesystem. I believe that the reason for that is that a file-based loopback that is stored on a journaled filesystem does not guarantee certain write ordering or that journaled filesystems depend on. But using a journaled filesystem on a device-based loopback should be fine. Isn't dm-crypt the new way of doing this? Doesn't that actually prevent you from using a file as the backend? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQsGj/HgHNmZLgCUhAQIQfQ//Wgvtu3G8sGFr7PMA4mWbZubEenh3nDln VRHOjN7EhgmHdGNLTqeMDODP9aFquEbqEQEJd3HGnmghJGlxc9qwzPotRBWSezBe 8cSYO71mpjXZjFikCZ7Or0+3EKO9i1ULSM+fFikE/IFyNNi2mr0raLzcTXmGE+Q/ umTu9hm6Df/BH15w1hZLvmmCMbA8/HvTicK1A0EUwM0OR5vYFF9TxoeZ5H759lR/ /HKUTEFFq5UFgTzIZhnhGEwzPbSIkqwMF0AOzy3joHuxG+G/37EpNbrPJSOGi8HY ej20UzMDDrHzmA3P0ZRvEoKLAB+4ABM5IFur7inzk8FPCP4ZOC4Mfyzd/VvG2F9G Gao3F+ElFgMEFawFMJFdmgvU4vsgAdBygBC+XUfaDDEOOWdKomfGuIKQH8x0hCuE eK7w6NBMGhj5hv/fk+7fjIi5uJxR8LCmMktJHykD/hcHek9o4ZPiyqGEHZqi3MDe /QJUeU2dyJP5MHz5o54exuwOtMmawz4sYyQgxUvO65iln8VdewMZRK4uM1FOxASk K0Tqrja0k4eqTbueFXEJ+c3dcjLSUMsu1QuEutLvbPQd+B8B8eFYao6/gr5NxIJ5 eK8tGxVmVCdmDBtmRuQascoudQDTCoy61xE3K/mJAYy/xuBIQ8cyrRxdac+mRD/Z GxQDZ+nA/gI= =QH/o -END PGP SIGNATURE-
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sean wrote: On Tue, June 28, 2005 10:01 am, Horst von Brand said: I don't belive that you want to see all reiser4-specific things as item plugins, disk format plugins in the VFS. Only what makes sense. Plus many of those will probably have to go. Decide on /one/ way of doing things, even if not perfect for all uses. Everything else is useless bloat. It doesn't seem to be a problem as long as loadable plugins are GPL. How Loadable how? reiser4 plugins must be compiled in, either directly to the kernel, or part of reiser4.ko The only thing loadable about them is that some can be turned on or off for individual files. is it useless bloat? It doesn't seem much different from having loadable modules in the security system. Just don't enable Reiser4 in your kernel if you don't want to use it. This is not getting us anywhere. It seems to be an issue of overall design and neatness at this point. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQsGkwXgHNmZLgCUhAQKUlw/6AxzaT+5R7lzhy4d/W55KY7m+8QJA90Ut 3m+E/hiSKykolERURKUoRPEK+jly8DUxLS+UpA5ZQwxzkR4YipMcoW5i3lHyJ9GB Hf9lBtGu0TwCF8W9Qh1Fk/7mwQcvyz6ATUYOYqvSA5Wxfr8BDFdcJUqTwMRCOxrA Fh5oOSBXEhqnSElfvurBkzMNurOmNnkpeZt8rM6qXqeYRRPrmIWmFGvkufoyb/q7 N2wdwtwoubWokl8FLWHQmH0f4pJqJUNXpDQvw67zKi24zOUq8ZZ7xH7EE8vNI9s9 ppVVsrLiAFE2/GeDRIdbQNSuClliq7XZV4AMHkorik7Qe0nIeR4hBr9hYI41l/Ie G3A9yP/69XsOodUWMZB/asxj3zMEhDynz26t98C2S858eRA7EJLcJ+IU1HnxHv7N KUcZLUyMP6DPDcm3r2FtjvwDwneQwk3zBqFE30DgAERZTgZ7RTglVuyBhETryk3m ZIf6bjuwnqn2/TFC7Yqwf9tzHshx91ywkfpOXwc/3IcrKKpfY74Mp4Cj/LkRemoz LnE6DdpjuNpMmwTwV0Vb5FKkfeO2nFkLZ96z8HphNmAAINh7gP3bpUMaODc8fLDG HtpzloYmBa4Yvn9JX+AwFuQStupPmScwa62Gcyv0Zm5EQ6fB1pqY1HdhpLHvXehT l0i+8OO74B0= =NI4M -END PGP SIGNATURE-
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hubert Chan wrote: On Tue, 28 Jun 2005 02:01:12 -0400, Kyle Moffett [EMAIL PROTECTED] said: On Jun 28, 2005, at 01:30:08, Hubert Chan wrote: On Tue, 28 Jun 2005 00:38:38 -0400, Kyle Moffett [EMAIL PROTECTED] said: Ok. Those things should probably be divided up. Stuff like POSIX extended attributes and such that have existing interfaces should use those. One of the claimed advantages of the '...' interface is that everything is editable as a file. So if someone wanted to edit the description extended attribute for foo.txt, he would just run [editor] foo.txt/.../description (or [editor] /meta/fs/$(getattrpath foo.txt)/description), instead of needing to use some special purpose editor. It works well for things like being able to use Gimp to edit a thumbnail or icon attribute. I don't disagree with the thumbnail/icon/description, but things like POSIX acls and extended attributes have _existing_ interfaces which should be used. Any existing interface should be supported, but Reiser4 seems to want to replace all existing interfaces except a direct open() and a proposed new system call which opens lots of small files at once, efficiently. The two approaches are not mutually exclusive, though. OK. I agree with that. Of course, Reiser4 can always present both interfaces, just like it presented two interfaces to the stat data -- the regular interface and the metas (now '...') interface -- before file-as-dir got disabled by default. The proposal I like right now is /meta, as a separate FS, which provides access to what would be the '...' interface. Check the archives. I don't deny them the right to add other interfaces later, but such should be a secondary or tertiary patch, after the rest of the stuff is in. In any case, if we were to provide an interface by which one could $EDITOR the POSIX ACLs, it should be done in the VFS where all filesystems can share it. I don't know if VFS is the right place for it, but I agree that it would be good to make it accessible to all filesystems. You put it in /meta, which is available to all filesystems. I think that part of Reiser4 needs more review than it's been given at present. Looking forward to the flamewar that happens when Namesys decides that file-as-dir is ready to be turned on again. ;-) Namesys still hasn't commented directly on the /meta proposal, have they? That would avoid the flamewar altogether. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQsGl6HgHNmZLgCUhAQK+OQ//Zhj9DPyXRaASbTmnj2oPcWYWHzY5+M8O n0e7PsFPtVpb6mduDPYu91WTGYooPnicVOBBQezWUOVFYMN4SWxyVunTpDYbvTGn xVwSLTjb5/AZ7dIuklVfverN72nwmLURCJjGZ41iqyylHJT/nCufYZHhQIPa15Pu o0IzYlQahS3uxuYVJubDOms0G/K2pDuoFGuJJkk+JTPCbf9+2UEqjiUrL3FTqeG+ 5RQ6wVeinz5CFPrUWmxl0CdipGqx3quCCYlBav31uRDJm2VwwqZNTxeEHWvZN/Y9 tXnkcVSVJkoaJtbGHUvu61g/TAs8ckxlEA9lnaG3SEhNNU5ZSm0aprZJTeRvs81e iFxzlOKdgZA11GNx8rnj04Ii5MJapgQhDlz5CbOCxvOm6SkZZul+3n6VHxlCJzH2 pQD/GFcynPAbZYitOAyTWAU9K+fZ98dbCkDKJRLMbT8uiZwoc/m59m9ZniDVEKAn IjUMFrIllpq9F8AZefEFqRV6l9vjM2vam5OS2HC4R+v753JEVKuvTjbJkR7mB9iv zEGPBciVOjZAWuWmeQVartnDwx4ic2SECxv25w32wcPcrXUs9w0Z/hpIUfG7EAUl z4dbGlKlXWybq8JLC6ojmL+cgKFAYs+4yfZvE73H9XHlhh1HrGbMc6sd342NCFJN WjYRbkxGym0= =LZpe -END PGP SIGNATURE-
Re: How to user reiser4 and crypt plugin ??
On Tue, 28 Jun 2005 14:24:45 -0500, David Masover [EMAIL PROTECTED] said: Hubert Chan wrote: But using a journaled filesystem on a device-based loopback should be fine. Isn't dm-crypt the new way of doing this? Yes and no. dm-crypt is recommended over cryptoloop. But there is also loop-AES, which is more secure (in some modes) than dm-crypt (currently). Doesn't that actually prevent you from using a file as the backend? Yes, I think so. -- 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: reiser4 plugins
On Tue, 28 Jun 2005 14:32:56 -0500, David Masover [EMAIL PROTECTED] said: Hubert Chan wrote: On Tue, 28 Jun 2005 02:01:12 -0400, Kyle Moffett [EMAIL PROTECTED] said: I don't deny them the right to add other interfaces later, but such should be a secondary or tertiary patch, after the rest of the stuff is in. In any case, if we were to provide an interface by which one could $EDITOR the POSIX ACLs, it should be done in the VFS where all filesystems can share it. I don't know if VFS is the right place for it, but I agree that it would be good to make it accessible to all filesystems. Sorry, accessible to all filesystems is incorrect terminology (it's backwards). What I meant was something more like able to access extended data from all filesystems. But I think everyone understands what I meant. You put it in /meta, which is available to all filesystems. Looking forward to the flamewar that happens when Namesys decides that file-as-dir is ready to be turned on again. ;-) Namesys still hasn't commented directly on the /meta proposal, have they? That would avoid the flamewar altogether. Well, we could still have a flamewar about whether metafs is useful, what type of functionality it should provide, etc. I'm sure we could find something to argue about. ;-) From a purely philosophical/aesthetic/theoretical point of view, I like file-as-dir much better than anything else, and would be ecstatic it if Namesys was able to make it work. From a practical/technical point of view, metafs may be an acceptable compromise. -- 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: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kyle Moffett wrote: On Jun 27, 2005, at 22:21:35, Hubert Chan wrote: On Mon, 27 Jun 2005 18:27:26 -0500, David Masover [EMAIL PROTECTED] said: Kyle Moffett wrote: I think the '...' is just a bad idea in general, because it breaks tar and such. An interface like this might be simpler to design and use: # mkdir /attr # mount -t attrfs attrfs /attr /attr/fd/$FD_NUM == '...' directory for a filedescriptor /attr/fs/$DEV_NUM/$INODE_NUM == '...' directory for an inode The most obvious (at least obvious for me) complaint about this is that the attributes are separate from the file. (In other words, it's a bit ugly. ;-) ) So if you want to backup a file, along with all its (extended) attributes (or substreams, or ... etc. ...), you need to backup the file, and find the appropriate /attr/fs/$DEV_NUM/$INODE_NUM and back that up. If I want to edit an attribute, I need to find $DEV_NUM and $INODE_NUM (which I have no idea how to do), rather than just edit foo/.../extended_attribute. (Or using your getattrpath command, it would be a two-step process -- run getattrpath, then run editor -- rather than a one-step process. Of course, this is only mildly annoying.) These are not really attributes so much as they are metadata, for example, a contents subdirectory, if one existed, would be based on the original file, and therefore non-unique, but would be looked up based on information about the original file. If you say so. I like the name meta because it looks cooler and is easier to type, but I could live with attr. It also exposes a difference between attributes and regular files. e.g. can I add attributes to an attribute? (say, I have a thumbnail attribute for the file ~/foo, and I want to add a mime-type attribute to that thumbnail attribute.) If you want to allow it, you have to be careful not to run into a big loop generating an infinite number of inodes in the attrfs. (e.g. /attr/fs/$(getattrpath /attr/fs/$(getattrpath ~/foo)/thumbnail)/ mimetype -- attrfs shouldn't generate the inode for that until /attr/fs/$(getattrpath~/foo)/thumbnail is accessed, and maybe not even then...) Agreed. I discuss this more below That said, I prefer that interface over xattr or openat. Absolutely. On the other hand, that's not to say it can't be improved. It would be usable from a shell with a simple getattrpath command which returns fs/$DEV_NUM/$INODE_NUM by stat-ing any given path. Still pretty annoying, but maybe a good idea, especially if the shell gets extended to support it. Not sure I like using inode numbers, though -- I like the idea of being able to symlink to stuff inside the meta-file dir. The advantage of using inodes rather than pathnames is that it is robust with respect to file renaming/moving. It also allows things like adding attributes to symlinks (since the inode number for a symlink is different from the inode number for the file that it points to). You can still symlink. It just takes a little more effort to figure out what $DEV_NUM/$INODE_NUM to use. Also, unlike a symlink, if the path doesn't change and the file does, it will break, also, if the file is removed and another created elsewhere, it will be redirected improperly. Perhaps a new symlink syntax is needed to allow attribute specification (Ick, more changes :-\). There are symlinks, and there are hardlinks. When I want a link to a file which doesn't change even if the file is moved, I use a hardlink. When I want a link to a particular location, even if the file there is deleted and then replaced, or if the file is not likely to move anytime soon, I use a symlink. Besides, can't we have it automagically figure out what the fs is once we give it the device number? I propose we should be able to have: /meta/$DEV_NUM/$INODE_NUM /meta/vfs/path/to/file That way, I can symlink to whichever is appropriate. Hans, thoughts? Seems to be namespace fragmentation, but seems usable, less breakage, and so on. And should it be /attr or /meta? For the mount point, it doesn't matter; it's up to the user. It's the attrfs or metafs or ???fs that matters (but which will greatly influence whether people user /attr or /meta). meta seems the more descriptive name. There should also probably be a somewhat standardized location for this, such that programs can locate it without much trouble. This mechanism would be usable from all FSs, and could be built into the VFS. Maybe. I think it should be its own FS, mountable and unmountable, just like /proc or /sys. It's a standardized location anyway, but easier to admin that way. But we definitely want to support multiple FSes. Even more reason to make it a separate system, accessible as its own mountable FS. Also, it would allow one to access the meta data of meta data (if supported by the filesystem, and possibly only
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregory Maxwell wrote: On 6/27/05, Hans Reiser [EMAIL PROTECTED] wrote: . But nevertheless it didn't survive, as like V3, with time V4 became slower and slower. In this case no year was needed, but just one month or alike. So end of test...but in fact I'll give V4 another go in the near future. Interesting that it got slower with time. It sounds like our online repacker is much needed. It will be a priority for after the kernel merge. Whered it go, I recall it being activated with: echo 1 /sys/fs/reiser4/*/repacker/start That proved to be unstable (on my box, the repacker never finished) and there was also some talk of making it only available commercially -- that is, pay some amount based on how much storage you're using it on, get the repacker. I like open source better, but whatever amount was proposed is more than fair for me, especially considering how fast stuff is even without the repacker. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQsGv0XgHNmZLgCUhAQKluQ/+Pjg6h5qUpO/6pG7v8ku2OhyUoR6aneTb FlqjaqNuxqKaT/C3iqZYLZ+YUk+MYdXKUYNthdlY9ZtaPNwnp34/AHUSLtU4Imgw Z4kIn3csKCkpeLRQMJ1o5nRSBwa+38Ta17ktYhn7L+ln53/ElULbPrmxjoSmA+SK ocjkVcUI8azJJosD1Y0tb5BSVa9PC+buPOgbkinvFVeme2ouwG+tAeAMECShface 0FbT1+Ai//S/t5rz/oz6BzlV+K7Jl+8OopFs9MnwD8Gqh21zeGiawLQGsDwvZuEt wJq73Y6b573RVJUy4dHAUqBZen0gar1GPWS2RpB3RwIYgb7/Ui3Rf5t//vTrZMNo Ej9R3AXcU82M8YHHmwr1QJfhrt7kddXPw5TSpA66RWNJdeFxoaXxja6sFFjQbSTs G5BHy2P/oHO8+uhbS+NI8T1N8KsrRrhJWr0pcjhHaoDogGdUj7TZtB+fANgLHbdV GstRVz8QvKGOZ8FrX/mMPzsfUbRx3pq+C/FJzSgqVI/4oTc/XIOS7cb92EC+1WrO KhYI3vy1zeKximboJXrPlr7QXkakjoOSFNH/MVzmF3sP1pe92hey7SXrpfgrOCOa 8gVo0u1tE98fuatl3MA8t3OGXGM5JXKpHVk/FiQt4358wAMmyDizvOeZ3GL1CA/M ixjK/caPrP0= =LFCF -END PGP SIGNATURE-
Re: How to user reiser4 and crypt plugin ??
On 6/28/05, Hubert Chan [EMAIL PROTECTED] wrote: Isn't dm-crypt the new way of doing this? Yes and no. dm-crypt is recommended over cryptoloop. But there is also loop-AES, which is more secure (in some modes) than dm-crypt (currently). There is now support for both LRW-AES and ESSIV in the mainstream kernel. With ESSIV the security should be the same as loop-aes and with LRW-AES potentially better. For the highest security you should also use the LUKS cryptosetup because it provides hardening for passwords.
Re: reiser4 plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hubert Chan wrote: On Mon, 27 Jun 2005 18:27:26 -0500, David Masover [EMAIL PROTECTED] said: Kyle Moffett wrote: I think the '...' is just a bad idea in general, because it breaks tar and such. An interface like this might be simpler to design and use: # mkdir /attr # mount -t attrfs attrfs /attr /attr/fd/$FD_NUM == '...' directory for a filedescriptor /attr/fs/$DEV_NUM/$INODE_NUM == '...' directory for an inode The most obvious (at least obvious for me) complaint about this is that the attributes are separate from the file. (In other words, it's a bit ugly. ;-) ) So if you want to backup a file, along with all its (extended) attributes (or substreams, or ... etc. ...), you need to backup the file, and find the appropriate /attr/fs/$DEV_NUM/$INODE_NUM and back that up. If I want to edit an attribute, I need to find $DEV_NUM and $INODE_NUM (which I have no idea how to do), rather than just edit foo/.../extended_attribute. (Or using your getattrpath command, it would be a two-step process -- run getattrpath, then run editor -- rather than a one-step process. Of course, this is only mildly annoying.) Especially considering you could add a tar/rsync flag to handle it for you. And most likely, each meta dir would have its own serialization method (read: file) so that you didn't find yourself trying to back up huge infinitely recursive structures, or accidentally triggering a huge tar operation, or something... It also exposes a difference between attributes and regular files. e.g. can I add attributes to an attribute? Under my scheme, yes, and it works the same way. (say, I have a thumbnail attribute for the file ~/foo, and I want to add a mime-type attribute to that thumbnail attribute.) If you want to allow it, you have to be careful not to run into a big loop generating an infinite number of inodes in the attrfs. I'm not sure if inodes are a problem, but this kind of stuff would be up to the fs, not the attrfs or metafs. That said, I prefer that interface over xattr or openat. Absolutely. But I think both should exist, so that programs currently using xattr will still work. Maybe you'd have: /meta/vfs/home/foo/attrs or something... Come to think of it, that changes the proposal a bit. You need a different way to access the meta-dir for files than for directories, if we're going to support /meta/vfs. No biggie: /meta/vfs/file/home/bob/sue.mpg/acl /meta/vfs/dir/home/bob/acl It would be usable from a shell with a simple getattrpath command which returns fs/$DEV_NUM/$INODE_NUM by stat-ing any given path. Still pretty annoying, but maybe a good idea, especially if the shell gets extended to support it. Not sure I like using inode numbers, though -- I like the idea of being able to symlink to stuff inside the meta-file dir. The advantage of using inodes rather than pathnames is that it is robust with respect to file renaming/moving. It also allows things like adding attributes to symlinks (since the inode number for a symlink is different from the inode number for the file that it points to). I think we need both interfaces, especially because the /meta/vfs interface makes looping easy. You can still symlink. It just takes a little more effort to figure out what $DEV_NUM/$INODE_NUM to use. Doesn't have the same effect. Actually, I like this. Give me some time to let it percolate. Hans, thoughts? Seems to be namespace fragmentation, but seems usable, less breakage, and so on. And should it be /attr or /meta? For the mount point, it doesn't matter; it's up to the user. No, it's not. It's up to the user and the application developers. Sure, I could mount /proc somewhere else, but that would confuse some things. Mounting /meta somewhere else would confuse even more things. It's the attrfs or metafs or ???fs that matters (but which will greatly influence whether people user /attr or /meta). True, but I think they should still hand down a decree of where it is to be mounted by default. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQsGxn3gHNmZLgCUhAQLWkg/+MIzXbygGoHubwLcw5SI1eeanVssukzF7 9kl+3qYcpbC6l/4fFkezBA8YCb8yy/VCfadAJ4Vgsr7T0rvGq1fvKIER6Q4LfU22 YCkHfU6dCnTmTjqHTFyYqZX95J6JXKUT/HCXn5AaYC5DIOYMp1gFHgj6P1wKOb/o KRvuOSIO0ta8fpPg6tBe6ve92sp99zqbacUplN+38+eBEIZUI7s7Dkg1lWX7ScyZ LVtHDEDJUuP0/Frq3xZHFKdgsVhoDtCm5Cl6EBX0OSubExPa/7ID2ANA+W01lqbm 9KMtXAcp/K8uOVkM8YDpFvvP2Ru/gp+iKy993lpGY9bEhIZ6BVz4zpVMvloHQe3a GCdsvub1yP7qQa/7LpkN6Shbw8W25iXcG0QUXa6XuiaJZIsVvRThrWOPXstx9GGQ KDZtMGIzH5vJcXQzIKzHMrfJBIKMmu3c/Et1EmdJy1t1PkH95+gGCrYc/nfBizfk NMYIp8S+RdGXwIcOWcwu4WspTJEZg1w7spXuydBZHd55YCq5JJE7lLNoK8Y3ZXks xC7b6Eo/0FgsxUmoQ9QYl9kzrxAejBGWmmTfsQGjFhu0Ep7jVCZHRRSq8r2RwRj/ AYY2JeFu7yRHsKy29BYipo0etR38Z5+Z0ZOn3iZZHHVz7D6u12U+69LXUEeyp46H mYzXXJOmIVA= =h/Gv -END PGP SIGNATURE-
Re: reiser4 plugins
On Tue, Jun 28, 2005 at 10:23:19AM +1000, Nick Piggin wrote: The scheduler interfaces are probably among the most stable in the kernel. Con was talking about internal implementation. Hmm, I'm by no means a kernel developer, but looking at the patches, it looked like the functions were just renamed and maybe something else was changed. I may be totally wrong here, and I apologize in advance if I am, but it seems to me like there would be no real need in changing some syntax? I get the feeling your friend is making up some tall tales if he says he rewrote the networking code to be much better than it is now. But I can guarantee him that if he has it will be of great interest to the network developers. Yeah, I just talked this over with him. [ IF THIS IS BULLSHIT, LET ME KNOW AND I'LL CORRECT HIM ;) POINTERS TO RELEVANT DOCUMENTATION ALSO WELCOME ;) ] His grudge was that conntrack was used everywhere, not like in 2.4, with a slow lookup in proc, that made it unusable for large nat systems. They wrote some reimplementation of the lookup part, which they didn't release. Then they figured out how to capture the packets before reaching conntrack and doing some mojo on them and reinjecting them somewhere later or bypassing conntrack altogether. However, his opinions were even less motivated than mine, it seems, as he didn't have anything except some ipfilter archives he read, where they cursed the Linux way of doing things. I haven't looked all too deeply into the network part, though, as I'm starting to get lazy and like to have a separate, dedicated piece of hardware do the network stuff for me... So maybe I should just retract my comments and look into every possible subsystem's development and see for myself, which I don't have time for :) I'm pretty sure it isn't a scheduler slowdown, but rather the system is getting disk bound. I think the reporter has performance back to 2.6.10 levels - it is actually something I still have to follow up on, but it is difficult because the reporter isn't able to share his code, although he's otherwise very helpful. It's just that for cases like these testing would be great. I'm not really sure how to do it, though, as it would require a lot of hardware and time and someone who can write a decent test suite. If anyone has links to good test suites, I'm all ears :) So, any chances of something being messed up in the disk part of the code? ...Too bad I just heard a big slowdown-in-disk-i/o curse was caused by dma falling off, for whatever reason (bug?) so that can't be used as forensics either :P If slowdowns do get merged, it is generally because they either haven't been reported until being merged or they make an accepted tradeoff. Not that they haven't been tested. Let's just get this straight, no amount of QA other than releasing a kernel and asking people to use it is going to find all the bugs that will be encountered. Would you think a separate dev tree would help here? I've also talked long with a guy from one of our major customers who says he's been losing faith in Linux over the past year, as his boxes are going oops or panicking every once in a while. The problem is that their system is too redundantly set up for a single oops or panic to matter much, so I haven't convinced them to report bugs. They'd rather boot the boxes and curse. He just figured it odd that this started happening after the new dev model, but the timelines are too granular for a real correlation. Just a strong gut feeling, and that's the kind of FUD that makes people look to *BSD, and a gut feeling that may have some merit to it, although it could never be proven. So don't take that as a flame or anything, just an observation :P Sure it must be difficult developing the kernel, if it were easier, I'd probably be at it too, but people don't like not being well informed of accepted tradeoffs, as they might not accept said tradeoff, and tracking what caused it may be too much. A lot of people out there don't like vendor kernels either, with 65536 backported patches and the 65537th voids your warranty. It's also probably very difficult to do analytical QA before submitting code, as bugs ALWAYS run through. But my gut tells me this -mm thing may not be the optimal way, as people are more scared of -mm, where some things may or may not work, than a separate dev tree, of which kerneltrap or whoever can post this is severely broken, test if you like and this seems to be going mostly strong now, test it on your everyday desktop A lot of complaints seem to come from people who use patchsets with half-assed backports and experimental code, having a separate tree may drive these people to use the experimental stuff knowing what it is, instead of believing their patch set is as good as vanilla. I mostly agree with you apart from your specific examples I think we could do things better, and most of us have made some big blunders, However there is just no way that bringing any
Re: reiser4 plugins
On Tue, Jun 28, 2005 at 09:44:59AM -0400, Horst von Brand wrote: No. But just relying on perfect hardware and concientious sysadmins is reckless. Hardware /is/ flaky, sysadmins /are/ (sometimes) lazy (and besides, today they are increasingly just plain Joe Sixpack users). Also, backing up a few hundred GiB is /not/ fun, and then keeping track of all the backups is messy. Even home users have started to set up raid mirrors at home now that disk space is cheap. That's a step in the right direction, I suppose, with hardware never being good. Taking backups in an environment where you need a few hundred GiB backed up is not that difficult. Get a separate, redundant box with a big tape changer and drop periodical backups off at your bank's vault. Get a separate, very reduntant box, with a truckload of proven drives in a separate raid box and run your stuff there. Get both of the above. If Joe Sixpack loses his mp3 collection, I don't really care, nor should anyone else. Anything important enough to care about is easy enough to back up. Always. Arrogance? Maybe. Also, I'm not claiming that they are /solely/ responsible, but not having the filesystem fall apart utterly every time some bug breaths on it /is/ a requirement. Reiserfs does not fall apart utterly every time some bug breaths on it. *still trying to understand how that can be* You haven't been around too much yet, do you? Rather I take backups, buy better hardware and understand there's a risk involved. Computers as a complete set can't be trusted, you can only make the best accomodations you can. -- mjt signature.asc Description: Digital signature
Re: reiser4 plugins
On Tue, 2005-06-28 at 23:47 +0300, Markus Törnqvist wrote: On Tue, Jun 28, 2005 at 09:44:59AM -0400, Horst von Brand wrote: No. But just relying on perfect hardware and concientious sysadmins is reckless. Hardware /is/ flaky, sysadmins /are/ (sometimes) lazy (and besides, today they are increasingly just plain Joe Sixpack users). Also, backing up a few hundred GiB is /not/ fun, and then keeping track of all the backups is messy. Even home users have started to set up raid mirrors at home now that disk space is cheap. That's a step in the right direction, I suppose, with hardware never being good. I've lost more data to my own recklessness and stupidity than filesystem corruption and hardware failure combined. RAID isn't really a good solution. My policy for cheap storage (currently the only variety I own) is when I buy a new hard drive, use the old drive for backups. The old drive is always large enough to hold everything I'd miss and then some. Home users should be capable of doing the same, assuming Windows has something similar to rsync. Taking backups in an environment where you need a few hundred GiB backed up is not that difficult. Get a separate, redundant box with a big tape changer and drop periodical backups off at your bank's vault. Get a separate, very reduntant box, with a truckload of proven drives in a separate raid box and run your stuff there. Get both of the above. If Joe Sixpack loses his mp3 collection, I don't really care, nor should anyone else. Anything important enough to care about is easy enough to back up. Always. Arrogance? Maybe. Also, I'm not claiming that they are /solely/ responsible, but not having the filesystem fall apart utterly every time some bug breaths on it /is/ a requirement. Reiserfs does not fall apart utterly every time some bug breaths on it. *still trying to understand how that can be* You haven't been around too much yet, do you? Rather I take backups, buy better hardware and understand there's a risk involved. Computers as a complete set can't be trusted, you can only make the best accomodations you can. -- Jake Maciejewski [EMAIL PROTECTED]
Re: How to user reiser4 and crypt plugin ??
On Tue, 28 Jun 2005 16:15:38 -0400, Gregory Maxwell [EMAIL PROTECTED] said: On 6/28/05, Hubert Chan [EMAIL PROTECTED] wrote: Isn't dm-crypt the new way of doing this? Yes and no. dm-crypt is recommended over cryptoloop. But there is also loop-AES, which is more secure (in some modes) than dm-crypt (currently). There is now support for both LRW-AES and ESSIV in the mainstream kernel. With ESSIV the security should be the same as loop-aes and with LRW-AES potentially better. Thanks for the info. I haven't look into the kernel for a little while -- I'm still using a slightly older version. For the highest security you should also use the LUKS cryptosetup because it provides hardening for passwords. -- 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: reiser4 plugins
On Tue, 28 Jun 2005 15:22:55 -0500, David Masover [EMAIL PROTECTED] said: Come to think of it, that changes the proposal a bit. You need a different way to access the meta-dir for files than for directories, if we're going to support /meta/vfs. No biggie: /meta/vfs/file/home/bob/sue.mpg/acl /meta/vfs/dir/home/bob/acl What if /home has an extended attribute named bob? Then is /meta/vfs/dir/home/bob a file or a directory? -- 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: reiser4 plugins
--- Diego Calleja [EMAIL PROTECTED] wrote: El Fri, 24 Jun 2005 21:31:02 -0700, Hans Reiser [EMAIL PROTECTED] escribió: What exactly is not ready Jeff? As I see it, this thread is 95% posturing, and almost no technical reasons for not merging. These authoritiesseem perfectly content with echoing the words of someone who skimmed the code and shot his mouth off without understanding it, and now these authorities just echo him because they like him and assume he must be right. I'm not one of those authorities but I doubt reiser4 will be merged at all with that attitude. Spot on. Somebody hasn't read his Linus. It seems to me that anytime I hear whining about how unfair the system is, how arbitrary patch rejection is, the flaw is either a lack of social competence, or failure to follow the submission guidelines. Lately the number three reason, Linus forgot, happens less and less. And linux developers are offering to help Reiser development fix what's wrong! That's above and beyond. If Hans wants to take his ball and go home, let it be understood that it is not because of a failure in the linux process. People that don't want flames, drop out of flame wars and do constructive work. People that want to talk ideology, start flame wars and perpetuate them. If you're having a code argument and you can go four posts without referring to actual code, you're no longer having a code argument. Non-demonstrable merit is not merit. Benchmarks can be necessary -- but are never alone sufficient -- merit to merge to mainline. Hans: consider that enough linux people like your stuff enough to have this argument. Performance has long since ceased to be at issue. Linux is a thing in itself. If Reiser4 is a thing in itself, and not merely a means to a further release point, you will care enough about it to merge it usably and maintainably into the kernel. Should you obsolesce 4 as you have done to 3, someone else can care enough about it, and do something with it. Features are added to Reiser3 because it is a thing in itself now that it is in the kernel. Its users care. Its maintainers, even if they still work for Namesys, care. Listen next time you hear someone talk about vendor-abandoned projects continuing to function through community development. Alan has said, Free software is always late. Free software follows the itch. If Hans wants linux to have Reiser4, Reiser development will work with linux development to become compliant and explain/adapt any additional functionality. Linux does not abjectly need Reiser4 in-tree. Reiser4 is ultimately Hans's scratch for Hans's itch. It will be the more effective and widely usable once it is stable in-tree, but the mainline kernel developers aren't the ones with the itch. Protocols exist in social systems as a means to constructively enlist the help of people outside the problem. The protocols here are well established. This is a patch meritocracy. Failure to comply further increases the lateness of Reiser4 in mainline kernels. Ego involvement is noise. My observations being what they are, may I suggest that this thread die, in favor of more eyes and in-depth current code analysis help in Re: reiser4 merging action list? Higher utility function; higher S:N. Flames can always go down with the ship. Frosty Not a programmer, merely literate. No, I don't usually respond to trolls, but this thread, from this man, itches me. It's not worthy of his brilliance, which may be his tragic flaw.
RE: XFS corruption during power-blackout
Hi Nathan,
You wrote: {
On Tue, Jun 28, 2005 at 12:08:05PM +0300, Al Boldi wrote:
True now, not so around 2.4.20 when XFS was rock-solid. I think they
tried to improve on performance and broke something. I wish they would
fix that because it forced me back to ext3, as in consistency over
performance any time.
Can you provide any details...
}
Specifically, in 2.4.20 I did an acid test:
Spawn 10 cp -a on some big dir like /usr.
Let it run for a few seconds, then pull the plug.
Don't reset-button, reset is different then pulling the plug.
Don't poweroff-button, poweroff is different then pulling the plug.
On reboot diff the dirs spawned.
What I found were 4 things in the dest dir:
1. Missing Dirs,Files. That's OK.
2. Files of size 0. That's acceptable.
3. Corrupted Files. That's unacceptable.
4. Corrupted Files with original fingerprint. That's ABSOLUTELY
unacceptable.
Ext3 performed best with minimal files of size 0.
XFS was second with more files of size 0.
Reiser,JFS was worst with corruptions.
When XFS was added into the vanilla-Kernel it caused corruptions like Reiser
and JFS, which forced me back to Ext3.
Re: reiser4 merging action list
Andrew Morton wrote: Hans Reiser [EMAIL PROTECTED] wrote: Andrew asked me to put together a list of things that need to be done before merging: Thanks. As I said to Hans, if we can get a list of bullet-point actions nailed down and agreed to then we have an uncontroversial path to happiness and a merge. Let's get down and concentrate on technical specifics. Hans, please maintain this list and republish it as we work through things. * VFS will dispatch directly to the method of the plugin for the *_operations methods. This requires duplicating to all plugin methods the common code currently used by all reiser4 plugins for a given method. It has the desirable side effect of making the methods more fully self-contained, which is somethng I had wanted two years ago and was a little sad to not get, and the cost of duplicating some code. Since not all plugin methods are *_operations, it means we have two structures with duplicated data, and duplicate data that must be in sync at all times is classical badness in programming technique (see Codd and normalization). vs owns this task * review all sparse complaints, and revise as appropriate. * panic and code beauty: everyone agrees that having function, file, and line added to reiser4_panic output hurts nothing (I hope). Everyone agrees that restarting the machine without an error message seems like a useless option to allow. Much else was argued, not sure if anything was a consensus view. Various detail improvements were suggested by Pecca, and I agreed with half of them. * metafiles should be disabled until we can present code that works right. Half the list thinks we cannot solve the cycles problem ever. Disable metafiles and postpone problem until working code, or the failure to produce it, makes it possible to do more than rant at each other. This is currently already done in the -mm patches, but is mentioned lest someone think it forgotten. * update the locking documentation There's also the custom list, hash and debug code. We should either a) remove them or b) generify them and submit as standalone works or c) justify them as custom-to-reiser4 and leave them as-is. either b) or c) is ok with me for the list code. The debug code should be c) I think. Probably vs can offer a more detailed and accurate opinion, Hans
