Re: Reiser4 support on parted ...
On Thu, May 05, 2005 at 05:10:08PM -0500, David Masover wrote: > To support doing what to Reiser4? > > "parted" is a disk management project -- specifically, a way to create, > delete, and resize partitions. Think of it as fdisk with nicer units > and built-in resizefs tools. > > This would, I think, involve creating a fully functional > resizefs.reiser4 -- something I distinctly remember Hans telling me not > to do, because my approach also created (most of) an online repacker, > which is something Hans wants to do for money. It would be possible to implement mkfs and fsck support only. Cheers, Andrew
Re: Reiser4 support on parted ...
On Thu, May 05, 2005 at 06:05:51PM -0500, David Masover wrote: > Couldn't this just be a wrapper to mkfs.reiser4 and fsck.reiser4? Almost. As it stands, libparted can't delegate out I/O to external programs, because its filesystem API address in terms of disk sectors rather than partitions. libparted could be improved to map sectors back to partitions for external communication, though. (I wonder if clever use of devicemapper could make this very simple?) Also, error handling (especially with i18n) could be somewhat painful with this approach. Cheers, Andrew
Re: Reiser4 repackers
On Thu, May 05, 2005 at 09:47:00PM -0500, David Masover wrote: > > Perhaps it would be a good idea to release at least an offline repacker. > > To be able to resize. That is the crucial feature. Performance isn't > quite so huge, although Hans may start squirming when someone benchmarks > performance before and after a year of normal use -- but asking users to > back up, recreate, and restore -- that's a bit much. Are you familiar with convertfs? http://members.optusnet.com.au/clausen/ideas/convertfs.txt Cheers, Andrew
Re: Reiser4 repackers
On Fri, May 06, 2005 at 11:41:16PM -0500, David Masover wrote: > > Are you familiar with convertfs? > > > > http://members.optusnet.com.au/clausen/ideas/convertfs.txt > > How easy is it to get the blocklist needed? It seems like Reiser4's > packing doesn't help here... The blocklist is only needed to find the blocks in the nested file, which is huge. (I don't know anything about reiser packing, but things like tail-merging aren't a serious problem.) > In both of these situations, convertfs seems workable, but overkill. I > mean, a proper resizer would leave the FS in a useable state no matter > which way it went or when power was cut. Convertfs means that if I lose > power at any point during the process, I'm very likely hosed, especially > with something doing lazy writes like Reiser4 as the original FS. And > this is all assuming it would work at all. You could do journalling in this process. (This would slow it down considerablly, however!) If you've got some nice gui like qtparted on a knoppix live cd, it could be quite convenient. > These are not situations where enterprise users would pay thousands of > dollars to be able to do this -- they can afford to do a full > backup/restore, just throw hardware at a problem and make it go away. > These are the scenario where small users like me tend to give up, back > up, reformat, and never touch such an inflexible FS again. Small users are happy to leave their computer overnight. Cheers, Andrew
Re: Reiser4 repackers
On Sat, May 07, 2005 at 08:10:18PM -0500, David Masover wrote: > > The blocklist is only needed to find the blocks in the nested file, > > which is huge. (I don't know anything about reiser packing, but > > things like tail-merging aren't a serious problem.) > > Yet, it's still a problem. You want a standardized way to map files to > underlying blocks, and before Reiser4, I'd say this was easy. But now, > who knows what the FS does to bastardize the file on the way down? > Crypto/compression? Tail-packing? Stenography? The possibilities are > endless... Can't you disable these things for the special nested file? You only need the block list for one file! > > Small users are happy to leave their computer overnight. > > Maybe you are, but newbies aren't. Maybe you got it wrong? Maybe you > got all your stuff moved around properly, but didn't leave room for a > swap partition? Looks like you have to start over! Ideally, you'd have a tool where you plan the entire job first (including creating the new swap partition), and then execute it in one hit. > Unless the newbies are following a VERY specific recipie or VERY good > tools, this process could easily take a few weeks, instead of a few > hours with the repacker. And that repacker looks easier to implement > than a noob-proof UI. Of course, people who know tell me I'm naive on > both counts... Clearly, a repacker would be better for users. > The current situation is not impossible, unless you want real users (not > fanboys) to choose Reiser4 over ANYTHING else. Why would I choose > Reiser4+convertfs over ReiserFS 3 + resize_reiserfs? Or even > ntfs+ntfsresize? Why do newbies ever choose reiserfs? Crypto? Cheers, Andrew
Re: [reiserfs-list] Storing partitioning info in the superblock (s_unused or BR)?
ool I haven't grokked, due > to "trying to fix 'em muckups" by $TOOL... (no, parted doesn't ring > a bell in that discipline :) Blame it on my bad experiences, will you? Well, if Parted screws anything up, I want to hear about it. > [3] I'm trying to learn C++ on that theme, i.e. I'm fooling around on the > idea of a partition-table(s)-backup tool... I doubt[4] it will be ever > useful, my point is, that I'm thinking about (parsing/interpreting) > the same kind of data[5] :) If you want to do that, could you build it on top of libparted? That way, you get partition table portability for free :-) And, as a bonus, you would also be able to convert between partition table formats... > [4] but still hope > > [5] is the dependency on libstdc++ a "BadIdea[tm]" for a backup tool? > It is (or rather would be) intended to be used on a functioning(!) > System, the recovery would be using dd (the skip= parameter will be > in the filename)... Ooops, I guess, this got far OT by now, so, please, > if you fancy to reply, do so via PM ;) I don't think it's a bad idea. Most ppl will use rescue CDs in future, and it's easy to fit it on. Andrew Clausen
Re: [reiserfs-list] resize_reiserfs problem
On Mon, Jan 07, 2002 at 04:43:07PM -0700, Andreas Dilger wrote: > Well, you can do it with cfdisk, it should be relatively easy to do in > your case. GNU parted is probably the best tool for doing complex > partition resizing tasks, but it does not appear to support reiserfs. There is a patch available for the unstable branch. (As of 2 days ago) Not something I'd trust at this stage... ;) > > p.d. sorry for my english > > Well, my espanol is worse, so don't worry about it. Sabe Portunhol? hehe Andrew
Re: [reiserfs-list] Re: magic is useless & Determining File Types
On Sat, Jan 12, 2002 at 03:32:00PM +0100, Xuan Baldauf wrote:
> Following the approach, you'd have to use those names:
>
> foo.jpeg/content
> foo.jpeg/content-type
> foo.jpeg/thumbnail.png/content
> foo.jpeg/thumbnail.png/content-type
>
> But this would not be compatible with the same approach above of naming
> metadata like this:
>
> foo.jpeg/content
> foo.jpeg/thumbnail.png
>
> Applications relying on finding the thumbnail using the name
> "foo.jpeg/thumbnail.png" would not find it anymore.
Why would they rely on using foo.jpeg/thumbnail.png, as opposed to
foo.jpeg/thumbnail.png/content?
BTW: why not foo/thumbnail/content? No point saying it's a jpeg twice
(in the filename, and the subdirectory)
> One could define that any metadata which has the chance to get metadata for
> itself has to be named in form of "${directory}/content", but you do not know
> in advance to which extend this applies to which metadata, so you would have
> to represent all data in that form (because all data is metadata in the sense
> of it's application, because all data states something about something),
> converting files into deep directory structures on the filesystem level. This
> would result in a tree-structured store of data (aka XML database). But this
> concept is too far, (and maybe too inefficient and complicated if mapped onto
> directories this way).
Why not support both options? If a file is a file, it's a file. (*grin*)
If a file is a directory with /content, then it's also a file ;)
> That is why you should not make a difference between the names of files and
> the names of files with attributes. If you do it, you do it like it is done in
> the programming language BASIC, where string variables are denoted as
> "variableName$" while integer variables are denoted as "variableName" (without
> the '$' mark). This is making the name of a file|variable dependent of it's
> type (in this case: real file or directory).
What does "name" mean in this context? How it's stored ondisk? How
it's addressed? (how it's addressed through syscalls? The GIMP?)
Andrew
Re: [reiserfs-list] Re: magic is useless & Determining File Types
On Sat, Jan 12, 2002 at 07:48:23PM +0100, Xuan Baldauf wrote:
> > Why would they rely on using foo.jpeg/thumbnail.png, as opposed to
> > foo.jpeg/thumbnail.png/content?
>
> Because there is a contract between the application and the filesystem that some
> entity (e.g. a file) can be found again using the same name which was used on
> creation of that entity.
I agree, but I don't see how this is inconsistent.
If you just store "thumbnail.png" (as opposed to thumbnail/content),
then there is no possibility of adding attributes.
> > Why not support both options? If a file is a file, it's a file. (*grin*)
> > If a file is a directory with /content, then it's also a file ;)
>
> That's my point. If attributes of files are implemented as directories, accessing
> those files with attributes must be downward compatible. If redirecting an
>
> open("foo.jpeg");
>
> to an
>
> open("foo.jpeg/content");
>
> within the kernel if foo.jpeg got changed to be an directory is possible and
> efficient, that could be okay from that viewpoint.
It seems better to implement this in user space. libgnomevfs, or something
like that.
> > What does "name" mean in this context?
>
> The text string to access the same data which was stored using the same name some
> time ago. So requiring the application to change
>
> open("foo.jpeg");
>
> to
>
> open("foo.jpeg/content");
All problems in software engineering can be solved by adding another
layer of indirection TM
Basically: on the shell, etc., I want to see foo/content as a directory
containing a file. When I use GNOME, I want to be able to see it both
ways. For applications that don't adopt this, no big deal... just pass
them file/content, instead of file.
Andrew
Re: [reiserfs-list] Recovering a file system not found by utilities
On Sat, Jan 26, 2002 at 07:48:05PM +0300, Vitaly Fertman wrote: > > Hi, > > it looks like a user error. We provide a support for $26 per hour. You have got to be kidding! debugreiserfs *SEGFAULTED*. And it looks like he found 2 other bugs. Everything he did looks 100% sane to me. Even if their is user error (I doubt it), you should give free support for finding bugs, IMHO. > > lectric# od -a /dev/archive/audio | less > > /R e I > > 0250060 stx nul stx nul R e I s E r 2 F s nul nul nul > > 0250100 etx nul nul nul eot nul x nul stx nul nul nul em nul nul nul > > 0250120 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul > > > > So there's something there. First 16 kilobytes were nul, but that's > > the way the should be? I can also find some of the file names too. It is how it should be. > > lectric# debugreiserfs /dev/archive/audio > > > > <-debugreiserfs, 2001-> > > reiserfsprogs 3.x.0j > > reiserfs_open: neither new nor old reiserfs format found on > > /dev/archive/audio print_block: buffer is NULL looks like a reiser bug > > lectric# debugreiserfs -s /dev/archive/audio > > > > <-debugreiserfs, 2001-> > > reiserfsprogs 3.x.0j > > reiserfs_open: neither new nor old reiserfs format found on > > /dev/archive/audio reiserfs_bitmap_load: fseek failed: No such file or > > directory obviously it exists. also, fseek can't return that error. Something is bonkers in reiser code. > > zsh: segmentation fault debugreiserfs -s /dev/archive/audio another bug. Andrew
Re: [reiserfs-list] Re: [PATCH] reisersfck speedup
On Fri, Jan 25, 2002 at 09:14:48AM -0500, Chris Mason wrote: > > > On Friday, January 25, 2002 10:23:28 PM +1100 Andrew Clausen > <[EMAIL PROTECTED]> wrote: > > >> - quote from Andi from a different thread -- > >> > > >> > mmap(NULL, ...) will be slow because it uses a linear search over all > >> > mappings of the current process. If you manage the address space > >> > yourself and specify an address to map to mmap it'll be fast because > >> > it uses an scalable data structure (AVL or RBtree) in this case. I > >> > would suggest doing that if you rely a lot on mmap with many mappings. > > > > So, isn't the way to do that malloc(3) and mmap(2)? The way to "manage the address space" is to malloc(3) buffers, and then mmap(2) them. malloc(3) (i.e. brk(2)) doesn't allocate buffers. Is this right? > > Or even read(2)/write(2) should achieve the same effect. (Why didn't I > > think of this before!) As you pointed out in private, this is incorrect. Thanks :) Andrew
Re: [reiserfs-list] EVMS Reiser FSIM
On Thu, May 30, 2002 at 04:56:33PM +0400, Hans Reiser wrote: > >On Wed, May 29, 2002 at 11:28:38AM -0500, Steve Pratt wrote: > >>I want to use the code approved by the owners of the file system. > > > >Me too. Just the ext2 maintainer doesn't like this approach, so > >I'm going to need to push a bit harder (and I don't have time now) > > I can imagine why he doesn't want to depend on the ext2 guys to find > time for reading his code, and you should not assume he is without good > reasons on this. Oh absolutely, and I agree 100%. (That was what I was saying!) > I have watched people try to get code into ext2. Yeah, Ted is rather conservative. But, it's good, because it forces you to be minimalist :) Andrew
Re: [reiserfs-list] EVMS Reiser FSIM
On Thu, May 30, 2002 at 02:02:06PM -0500, Steve Pratt wrote: > >Me too. Just the ext2 maintainer doesn't like this approach, so > >I'm going to need to push a bit harder (and I don't have time now) > > That is the major benefit of current EVMS implementation, I don't need the > FS developers to actually do anything. Well, I prefer to leave a system broken than to patch over it. Leaving it broken encourages someone to fix it properly. (And also, saves me time from doing work that won't be used long-term) I doubt a philosophy like that would go down to well in IBM, but I think it's one reason for GNU/Linux's success. (It is a good philosophy if you don't have many resources... but IBM has different problems... like solving real-world problems to get $$$ ;) > >I believe his point was: it would be possible to write non-GPL FSIMs. > >(The GPL is probably unenforceable for "plugins") > > Yes, this would allow a FSIM plugin(GPL or not) to invoke non-GPL > utilities. Yura and rms weren't too excited about this possibility. I'm not either, but I think the system architecture is more important than the licence in this case (the practical difference the licence thing would make is sooo small...) > >The obvious long-term solution is to get jfs people to make a decent > >library. fork/pipe is Wrong. > > I agree that libraries have advantages. When available, we can always > changes the FSIMs. I could probably make all the necessary the changes in > a couple of days. Right. > To have multiple components and libraries interact safely and correctly > there must be a structure for each to adhere to. As you point out, one did > not exist in Linux. EVMS created one. Is it perfect, absolutely not, but > I think it is pretty good. Well, it would be nice if it was more componentized, with less cross-dependencies, etc. More minimalist. > For example we added a S/390 segment manager > and a GPT segment manager without having to change a single API or line of > common code. Must be pretty modular if we can accomplish that. No, it just means your abstraction for seg managers is, actually, abstract. (libparted has the same properties... except perhaps for flags) I think it's good that you have those properties, but you lack some others: (1) portability (2) you didn't reuse linux-lvm code... which is a result of (1), right? (The engine wants to talk to the EVMS engine, not the linux-lvm kernel implementation. This enforces lots of coupling, making reuse of linux-lvm too hard) (3) it seems complicated. Lots of ideas that look similar aren't actually grouped together to share code. (FSIMs and plugins share a lot, for example) > 2 weeks > ago the support for Resiser was just an entry in a todo list, now it is > done, not bad since I spent less than half my time on it. I'm sure you could use libreiserfs in the same amount of time, and make something that integrates with EVMS much better ;) > We will continue to look for ways to improve EVMS, but I think the time has > passed for major architecture changes. Well, I think the above are major changes, and useful to make. That said, 'major' doesn't mean time-consuming. It just means lots of change. (But, in my experience, just lots of cut&paste) I think it's adventurous to claim that any piece of software has "passed the time for major architecture changes". Name one project that declared that 5 years ago, and hasn't made such changes. Bonus points if they were the first to implement that class of system. (EVMS is basically in that boat!) Andrew
Re: what do you do that stresses your filesystem?
On Mon, Dec 23, 2002 at 02:28:32PM +0300, Hans Reiser wrote: > We were discussing how to optimize reiser4 best, and came to realize > that us developers did not have a good enough intuition for what users > do that stresses their filesystem enough that they care about its > performance. Something else you might want to do is measure "commit latency"... the time between file operations being made by userland, and those operations becoming durable (i.e. getting committed into the log). If you can benchmark this, it might give users more confidence. (When I clicked save, it did, actually, save!) This is kind of related to real-time stuff, which is another thing you might want to test. Eg: audio/video playback... can reiserfs sustain IO bandwidth well, without falling behind occasionally? (i.e. maintaining low latency) XFS has (had? I think it's only the irix port) an ioctl to tell the OS "I want to read 300kb/s with maximum 0.1ms latency on fd 3". (The ioctl() would fail if Irix couldn't guarantee that) I'm not saying this is useful for everyone, just it should help you understand the performance better... Cheers, Andrew
