Re: File as a directory - VFS Changes
Nikita Danilov wrote on Wed, 1 Jun 2005 14:58:47 +0400: > For example: mv /d0 /d1 > > To check that this doesn't introduce a cycle one has to load each child > of /d0 (which may be millions) and recursively check that from none of > them /d1 is reachable. This has to be done on each rename. I believe > this is unacceptable overhead. That's where we differ. I think it is an acceptable overhead. It also only happens on rename and delete operations for objects with multiple parents or descendants. If you just move or delete an ordinary file that's got just one parent directory and no children, the cost is ordinary too. If it's a fildirute object with a dozen attribute type things as children, then it will need to traverse those dozen children. Not a big deal. Consider this example: The typical worst case operation will be deleting a link to your photo from a directory you decided didn't classify it properly. The photo may be in several directories, such as Cottage, Aunt and Bottles if it is a picture of a champaign bottle you polished off at your aunt's cottage. You decide that it shouldn't really be in the Aunt folder, so you delete it (or rather the link) from there. The traversal starts with recursively finding all the children of the deleted object, which will include the photo and all attributish subobjects (thumbnail, description, ...). Not too bad, maybe a dozen objects. Then reconnect those children to objects which have a known good path to the root, reached through whatever parents remain. That path through the new link becomes their true path name. The photo goes first, finding one of the alternative parent directories, say Cottage as its new main parent. Then the other children find the Photo as their main parent. In other words, the cycle checker has to find all the children of the deleted object(s). In most cases there aren't very many of them. Now if you move the directory containing millions of files, then it's going to take a while. And if it has a hard link down to another directory, that gets traversed too. But that won't happen too often, only around spring time when you're reorganizing your mail archives. - Alex
Re: File as a directory - VFS Changes
Hans Reiser wrote on Tue, 31 May 2005 11:32:04 -0700: > What about if we have it that only the first name a directory is created > with counts towards its reference count, and that if the directory is > moved if it is moved from its first name, the new name becomes the one > that counts towards the reference count? A bit of a hack, but would work. Sounds a lot like what I did earlier. Files got really deleted when the true name was the only name for a file (only one parent in other words). But I also had a large cycle finding pause when any file movement happened. I'm not sure if it would still be needed. Nikita Danilov wrote: > - if garbage collection is implemented through the reference counting > (which is the only known way tractable for a file system), then cycles > are never collected. > [...] > But the garbage collection problem is still there. You are more than > welcome to solve it by implementing generation mark-and-sweep GC on file > system scale. :-) There are at least two choices: Bite the bullet and have a file system that is occasionally slow due to cycle checking, but only when the user somehow makes a huge cycle. Keep in mind that this only happens when you use the new functionality, if you only create files with one parent, it should be as fast as regular file systems. I see its features being useful for desktop use, not servers, so the occasional speed hit is less annoyance than the lack of features (the ability to file your files in several places). Another way is to not delete the files when they get unlinked. Similar to some other allocation management systems, have a background thread doing the garbage collection and cycle tracing. The drawback is that you might run out of disc space if you're creating files faster than the collector is cleaning up. I wonder if you can combine a wandering journal (or whatever it is called, where the journalled data blocks become the file's current contents) with the copy type garbage collection (is that the same as a 2 generation mark and sweep?). Copy type collection copies all known reachable objects to an empty half of the disk. When that's done, the original half is marked empty and the next pass copies in the other direction. Could work nicely if you have two disk drives. Yet another PhD topic on garbage collection for someone to research :-) There are lots of other garbage collection schemes that might be applicable to file systems with cycles. It could work, maybe with decent speed too! - Alex
$ Judgments
Be the Boss. Flexibility in the work days and hrs. Your O F F I C E and be anywhere. 5,000US to 12,000US PM. Substantial profit handling $ Judgments. Excellent training and assistance. http://bgb.3M5B.extrasitemsonlines.com/b/ Additional info or to discontinue receiving or to see our address. But he said something in French to a waiter who was passing, and the latter came to Rob and made a low bow. I speak ze Eengliss ver' fine, he said What desire have you? What are your rates by the day? asked the boy
Penis Enlargement announcement
Penis enhancement system that works for countless men worldwide. http://www.jnaz.net/ss/ What luck for rulers that men do not think. The strongest man in the world is the man who stands alone. What is virtue but the trades unionism of the married. The actions of men are the best interpreters of their thoughts. Last week, I went to Philadelphia, but it was closed.
Re: reiser4 on large block devices
On Wed, Jun 01, 2005 at 07:56:05PM +0200, Adrian Ulrich wrote: > > > ReiserFS: sda3: warning: sh-2021: reiserfs_fill_super: can not find > > reiserfs on sda3 > > Ehrm, This sounds like Reiser3, > does your kernel support Reiser4? Maybe you should use modprobe? You would be correct. I had assumed 2.6.11.* defaulted to reiser4. Everything seems to be working now.
NinetyDollars for WinXPandOfficeXP
www.la70623rpwla043.tritylbcgbj.com
Re: File as a directory - VFS Changes
On Wed, 2005-06-01 at 21:27 +0400, Nikita Danilov wrote: [snip] > Frankly speaking, I suspect that name-as-attribute is going to limit > usability of file system significantly. > > Note, that in the "real world", only names from quite limited class are > attributes of objects, viz. /proper names/ like "France", or "Jonathan > Briggs". Communication wouldn't get any far if only proper names were > allowed. > > Nikita. Bringing up /proper names/ from the real world agrees with my idea though! :-) As a person, you have a list of "proper names" that you answer to and that you prefer. However, in some cases you will also answer to "Hey, you over there!" or "Someone who left a white Honda in the parking lot, please turn your lights off." So a file could have a list of proper names, but it can also be referred to in any other way and by any other name. Proper names would be preferred, though. -- Jonathan Briggs <[EMAIL PROTECTED]> eSoft, Inc. signature.asc Description: This is a digitally signed message part
Schwarzenegger, just 10 minutes
New softtabs, thay last longer and have less sideeffects World wide delivery No prescription needed Private online ordering http://Wood.hybridisms.com/?897 want to discontinue, go here http://Roland.hurtfully.com/rm.php?897
Re: reiser4 on large block devices
> ReiserFS: sda3: warning: sh-2021: reiserfs_fill_super: can not find > reiserfs on sda3 Ehrm, This sounds like Reiser3, does your kernel support Reiser4? Maybe you should use modprobe? -- We're working on it, slowly but surely...or not-so-surely in the spots we're not so sure... -- Larry Wall
Re: File as a directory - VFS Changes
Jonathan Briggs writes: [...] > > However, query directories (or "smart folders") will have this namespace > problem in every case and there is no avoiding it. If the query is for > every file modified in the past day, the file path through the query > directory is not going to match any given name of the file. Same for > keyword queries, ownership queries, or whatever. Which I think exactly points to one fundamental problem with the idea that names are attributes of object: this idea is incompatible with the notion of dynamically created "views" that in effect add new paths through which objects are reachable. These paths _are_ names as far as user is concerned (after all names exist to reach objects), but they are not in the name-as-attribute model. > > In the traditional directory system, a file doesn't have an official > name, just links to it from directory entries. Perhaps if you think of > the proposed "name" meta-data as a "preferred name" the idea would work > better for you? Frankly speaking, I suspect that name-as-attribute is going to limit usability of file system significantly. Note, that in the "real world", only names from quite limited class are attributes of objects, viz. /proper names/ like "France", or "Jonathan Briggs". Communication wouldn't get any far if only proper names were allowed. Nikita.
Re: reiser4 on large block devices
On Wed, Jun 01, 2005 at 04:42:33PM +0400, Vitaly Fertman wrote: > would you try this patch for libaal-1.0.4? mkreiser4 completes without errors now, but attempting to mount the filesystem gives: ReiserFS: sda3: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on sda3
Re: File as a directory - VFS Changes
On Wed, 2005-06-01 at 18:42 +0400, Nikita Danilov wrote:
> Jonathan Briggs writes:
> > On Wed, 2005-06-01 at 14:43 +0400, Nikita Danilov wrote:
> > > Nikita Danilov writes:
>
> [...]
>
> > >
> > > That latter bit, about making them persistent, is where the trouble
> > > begins: once queries acquire identity and a place in the file system
> > > name-space, they logically become part of that very name-space they are
> > > querying! This leads to various complication, and you are trying to work
> > > around them by claiming that queries are not _always_ part of name-space
> > > ("file1 [only] **appears** to be a child..."). This non-uniform behavior
> > > is a big disadvantage.
> >
> > In this scheme, query objects were always part of the name-space.
>
> Then, paths visible through queries are inconsistent with names of
> underlying objects. You querying system returns fake results
> ("/tmp/A/B/C/A/file1") that are not present in the database queries are
> ran against. This is *wrong*. Nobody is going to tolerate DBMS that
> sometimes returns extra rows in SELECT statement, right?
If you wished to enforce name-query directories always having a single
name and their query always being identical to their name, then that
wouldn't happen.
However, query directories (or "smart folders") will have this namespace
problem in every case and there is no avoiding it. If the query is for
every file modified in the past day, the file path through the query
directory is not going to match any given name of the file. Same for
keyword queries, ownership queries, or whatever.
In the traditional directory system, a file doesn't have an official
name, just links to it from directory entries. Perhaps if you think of
the proposed "name" meta-data as a "preferred name" the idea would work
better for you?
--
Jonathan Briggs <[EMAIL PROTECTED]>
eSoft, Inc.
signature.asc
Description: This is a digitally signed message part
Re: File as a directory - VFS Changes
Jonathan Briggs writes:
> On Wed, 2005-06-01 at 14:43 +0400, Nikita Danilov wrote:
> > Nikita Danilov writes:
[...]
> >
> > That latter bit, about making them persistent, is where the trouble
> > begins: once queries acquire identity and a place in the file system
> > name-space, they logically become part of that very name-space they are
> > querying! This leads to various complication, and you are trying to work
> > around them by claiming that queries are not _always_ part of name-space
> > ("file1 [only] **appears** to be a child..."). This non-uniform behavior
> > is a big disadvantage.
>
> In this scheme, query objects were always part of the name-space.
Then, paths visible through queries are inconsistent with names of
underlying objects. You querying system returns fake results
("/tmp/A/B/C/A/file1") that are not present in the database queries are
ran against. This is *wrong*. Nobody is going to tolerate DBMS that
sometimes returns extra rows in SELECT statement, right?
[...]
>
> The user is responsible for sensible naming. Under normal use, a user
> would hardly notice the difference between traditional directories and
> this name-query system.
Heh, this assumes that users will continue to use new namespace as they
use old one. Which is not true. Usage is determined by features
provided. This is, by the way, one of driving forces behind reiserfs
support for small files and large directories.
If file system provides ability to create namespaces in the form of
arbitrary graphs, this will be used.
Nikita.
Re: File as a directory - VFS Changes
On Wed, 2005-06-01 at 14:43 +0400, Nikita Danilov wrote:
> Nikita Danilov writes:
>
> [...]
>
> >
> > >
> > > Yes. :-) It is radical, and the idea is taken from databases. I
> > > thought that seemed to be the direction Reiser filesystems were moving.
> > > In this scheme a name is just another bit of metadata and not
> > > first-class important information. The name-query directories would be
> > > there for traditional filesystem users and Unix compatibility. They
> > > would probably be virtual and dynamic, only being created when needed
> > > and only being persistent if assigned meta-data (extra names (links),
> > > non-default permission bits, etc) or for performance reasons (faster to
> > > load from cache than searching every file).
> >
> > That latter bit, about making them persistent, is where the tr
> >
>
> [Hmm... grue ate my message.]
>
> That latter bit, about making them persistent, is where the trouble
> begins: once queries acquire identity and a place in the file system
> name-space, they logically become part of that very name-space they are
> querying! This leads to various complication, and you are trying to work
> around them by claiming that queries are not _always_ part of name-space
> ("file1 [only] **appears** to be a child..."). This non-uniform behavior
> is a big disadvantage.
In this scheme, query objects were always part of the name-space.
None of the objects are really children of any of the others. They only
appear to be children when viewed through a set of name-query
directories. In reality every object would be an equal in the true OID
name-space. Only meta-data objects are children of their data objects.
You could also create a confusing query named /tmp/G that returned
results for /usr/lib/. This is the same sort of abuse that creates
A->B->C->A loops: the query was deliberately set to have a misleading
name/name-query relationship.
The user is responsible for sensible naming. Under normal use, a user
would hardly notice the difference between traditional directories and
this name-query system.
With persistent disk cache of queries and lookup tables for common
names, it does start to look like regular directory structures, but it
is still coming at the problem from the opposite direction. Traditional
directories store information about a file (its name) outside the file,
and this system would store everything about a file with the file
itself.
--
Jonathan Briggs <[EMAIL PROTECTED]>
eSoft, Inc.
signature.asc
Description: This is a digitally signed message part
Re: Reiserfsck 1300Gig failed with following error
Situation : LVM with reiserfs 2 onboard IDE controllers => 8 disks I can't connect another disk fysicly perform dd_rescue'ing on another computer. or alternatively you can pull out a working disk out, put a new one, dd_rescue the broken one to a new one, put the new one instead of the broken one and put the pulled out disk back to its own place. Omg omg! How I didn't think of that :) thanx. system boots from a scsi disk, that has nothing to do with the LVM except booting and mounting it . What should I do before I pay you to work out a solution. thanx. kind regardes, Matthias. -- Matthias Barremaecker, MH.BE - Arta nv 0495 30 31 72 http://mh.be/ SERVER HOUSING per 1HE € 50 per maand 20Gig traffic, 100Mbit netwerk Center te Antwerpen.
Re: Reiserfsck 1300Gig failed with following error
On Wednesday 01 June 2005 16:28, Matthias Barremaecker wrote: > >>How do you sugest I swap a hd in a LVM raid with already data on it ? > > > > > > dd_rescue hd to a relable one & change lvm according to the change. > > if you need our assistance please use our www.namesys.com/support.html > > service. > > I start to find that answer super funny.:)) I'm willing to pay if you > fix my problem. Maybe you can start saying if the problem is fixable. > > Situation : > > LVM with reiserfs > > 2 onboard IDE controllers => 8 disks > > I can't connect another disk fysicly perform dd_rescue'ing on another computer. or alternatively you can pull out a working disk out, put a new one, dd_rescue the broken one to a new one, put the new one instead of the broken one and put the pulled out disk back to its own place. > system boots from a scsi disk, that has nothing to do with the LVM > except booting and mounting it . > > What should I do before I pay you to work out a solution. > > thanx. > > kind regardes, > > > Matthias. > > > -- Thanks, Vitaly Fertman
Re: reiser4 on large block devices
On Tuesday 31 May 2005 22:42, Aaron Porter wrote:
>
> I'm trying to create a reiser4 filesystem on a ~4tb block device,
> but I'm getting the error "Fatal: The partition size is too big." The FAQ
> seems to list a max filesystem size of 16tb. Am I missing something?
>
> diablo:~# mkreiser4 /dev/sda3
> mkreiser4 1.0.4
> Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by
> reiser4progs/COPYING.
>
> Block size 4096 will be used.
> Linux 2.6.11.8 is detected.
> Uuid f22c4f94-4fcd-4655-b4e0-6665048db8ce will be used.
> Fatal: The partition size is too big.
> Reiser4 is going to be created on /dev/sda3.
> (Yes/No): no
> diablo:~#
would you try this patch for libaal-1.0.4?
--
Thanks,
Vitaly Fertman
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/21 13:15:23+03:00 [EMAIL PROTECTED]
# use BLKBLKGETSIZE & BLKGETSIZE6464 defines
#
# file.c:
# do not limit file size by 2^41 bytes
#
# configure.in:
# check for large files correctly
#
# src/file.c
# 2005/03/21 13:14:02+03:00 [EMAIL PROTECTED] +3 -4
#
# src/file.c
# 2005/03/21 12:40:49+03:00 [EMAIL PROTECTED] +3 -14
# do not limit file size by 2^41 bytes
#
# configure.in
# 2005/03/21 12:40:29+03:00 [EMAIL PROTECTED] +1 -1
# check for large files correctly
#
diff -Nru a/configure.in b/configure.in
--- a/configure.in 2005-06-01 15:50:06 +04:00
+++ b/configure.in 2005-06-01 15:50:06 +04:00
@@ -136,7 +136,7 @@
GENERIC_CFLAGS="$GENERIC_CFLAGS -D_REENTRANT"
AC_SYS_LARGEFILE
-if test -z "${ac_cv_sys_file_offset_bits}"; then
+if test x${ac_cv_sys_file_offset_bits} = xno; then
AC_MSG_WARN(Can't detect right _FILE_OFFSET_BITS. Will be forced to 64bit.)
ac_cv_sys_file_offset_bits=64
fi
diff -Nru a/src/file.c b/src/file.c
--- a/src/file.c 2005-06-01 15:50:06 +04:00
+++ b/src/file.c 2005-06-01 15:50:06 +04:00
@@ -18,6 +18,9 @@
#include
#include
+/* BLKGETSIZE & BLKGETSIZE64 defines: */
+#include
+
#include
/* Function for saving last error message into device assosiated buffer */
@@ -193,10 +196,6 @@
return !aal_strncmp(file1, file2, aal_strlen(file1));
}
-#if defined(__linux__) && defined(_IOR) && !defined(BLKGETSIZE64)
-# define BLKGETSIZE64 _IOR(0x12, 114, uint64_t)
-#endif
-
/* Handler for "len" operation for use with file device. See bellow for
understanding where it is used. */
static count_t file_len(
@@ -209,18 +208,8 @@
return INVAL_BLK;
#ifdef BLKGETSIZE64
- if ((int)ioctl(*((int *)device->entity), BLKGETSIZE64, &size) >= (int)0) {
- uint32_t block_count;
-
- size = (size / 4096) * 4096 / device->blksize;
- block_count = size;
-
- if ((uint64_t)block_count != size) {
- aal_fatal("The partition size is too big.");
- return INVAL_BLK;
- }
-
- return (count_t)block_count;
+ if (ioctl(*((int *)device->entity), BLKGETSIZE64, &size) >= 0) {
+ return size / device->blksize;
}
#endif
@@ -231,8 +220,7 @@
if (ioctl(*((int *)device->entity), BLKGETSIZE, &l_size) >= 0) {
size = l_size;
- return (count_t)((size * 512 / 4096) * 4096 /
-device->blksize);
+ return size * 512 / device->blksize;
}
}
Re: Reiserfsck 1300Gig failed with following error
How do you sugest I swap a hd in a LVM raid with already data on it ? dd_rescue hd to a relable one & change lvm according to the change. if you need our assistance please use our www.namesys.com/support.html service. I start to find that answer super funny.:)) I'm willing to pay if you fix my problem. Maybe you can start saying if the problem is fixable. Situation : LVM with reiserfs 2 onboard IDE controllers => 8 disks I can't connect another disk fysicly system boots from a scsi disk, that has nothing to do with the LVM except booting and mounting it . What should I do before I pay you to work out a solution. thanx. kind regardes, Matthias. -- Matthias Barremaecker, MH.BE - Arta nv 0495 30 31 72 http://mh.be/ SERVER HOUSING per 1HE € 50 per maand 20Gig traffic, 100Mbit netwerk Center te Antwerpen.
Re: Reiserfsck 1300Gig failed with following error
On Wednesday 01 June 2005 14:57, Matthias Barremaecker wrote: > Hi, > > > the key (which is in the tree already and supposed to be correct) is > > completely corrupted, no one key component is correct. data could be > > corrupted in the memory or on read/write -- bad cable, controller, > > dying harddrive, etc. > > > > > >>Anyone any suggestions ? > > > > > > running fsck with the list of bad blocks is useful when you have the > > known fixed number of bad blocks, you know that the number will not > > change soon, in other words other blocks are relable. > > > > first of all you even have not complete badblocks run, so you cannot > > be sure you know the full bad block list. > > > > and the second, if your hardware is dying you need to fix it before > > running fsck on it. > > How do you sugest I swap a hd in a LVM raid with already data on it ? dd_rescue hd to a relable one & change lvm according to the change. if you need our assistance please use our www.namesys.com/support.html service. -- Thanks, Vitaly Fertman
Re: File as a directory - VFS Changes
Alexander G. M. Smith writes: > Nikita Danilov wrote on Tue, 31 May 2005 13:34:55 +0400: > > Cycle may consists of more graph nodes than fits into memory. Cycle > > detection is crucial for rename semantics, and if > > cycle-just-about-to-be-formed doesn't fit into memory it's not clear how > > to detect it, because tree has to be locked while checked for cycles, and > > one definitely doesn't want to keep such a lock over IO. > > Sometimes you'll just have to return an error code if the rename operation > is too complex to be done. The user will have to then delete individual > leaf files to make the situation simpler. I hope this won't happen very > often. Huh? How are you planning to check that adding new edge to the graph does not introduce a cycle without inspecting all nodes of that graph at least once (note: you don't know what other objects contain references to the given one, only out-going edges are known)? For example: mv /d0 /d1 To check that this doesn't introduce a cycle one has to load each child of /d0 (which may be millions) and recursively check that from none of them /d1 is reachable. This has to be done on each rename. I believe this is unacceptable overhead. > > On the plus side, the detection of all the files that may be affected > means you can now delete a directory directly, contents and all, if all > the related inodes fit into memory. > > - Alex > Nikita.
Re: File as a directory - VFS Changes
Nikita Danilov writes:
[...]
>
> >
> > Yes. :-) It is radical, and the idea is taken from databases. I
> > thought that seemed to be the direction Reiser filesystems were moving.
> > In this scheme a name is just another bit of metadata and not
> > first-class important information. The name-query directories would be
> > there for traditional filesystem users and Unix compatibility. They
> > would probably be virtual and dynamic, only being created when needed
> > and only being persistent if assigned meta-data (extra names (links),
> > non-default permission bits, etc) or for performance reasons (faster to
> > load from cache than searching every file).
>
> That latter bit, about making them persistent, is where the tr
>
[Hmm... grue ate my message.]
That latter bit, about making them persistent, is where the trouble
begins: once queries acquire identity and a place in the file system
name-space, they logically become part of that very name-space they are
querying! This leads to various complication, and you are trying to work
around them by claiming that queries are not _always_ part of name-space
("file1 [only] **appears** to be a child..."). This non-uniform behavior
is a big disadvantage.
Nikita.
Re: Reiserfsck 1300Gig failed with following error
Hi, the key (which is in the tree already and supposed to be correct) is completely corrupted, no one key component is correct. data could be corrupted in the memory or on read/write -- bad cable, controller, dying harddrive, etc. Anyone any suggestions ? running fsck with the list of bad blocks is useful when you have the known fixed number of bad blocks, you know that the number will not change soon, in other words other blocks are relable. first of all you even have not complete badblocks run, so you cannot be sure you know the full bad block list. and the second, if your hardware is dying you need to fix it before running fsck on it. How do you sugest I swap a hd in a LVM raid with already data on it ? thanx. kind regardes, Matthias. -- Matthias Barremaecker, MH.BE - Arta nv 0495 30 31 72 http://mh.be/ SERVER HOUSING per 1HE € 50 per maand 20Gig traffic, 100Mbit netwerk Center te Antwerpen.
Re: File as a directory - VFS Changes
Jonathan Briggs writes:
> On Wed, 2005-06-01 at 02:36 +0400, Nikita Danilov wrote:
[...]
> >
> > One problem with the above is that directory structure is inconsistent
> > with lists of names associated with objects. For example, file1 is a
> > child of /tmp/A/B/C/A, but Object 1001 doesn't list /tmp/A/B/C/A/file1
> > among its names.
>
> file1 *appears* to be a child because it is actually returned as the
> query result for its name of /tmp/A/file1 because A is a query
I beg your pardon, but this is confusing. Objects have "real" names that
are stings attached to them. User, on the other hand, accesses objects
through paths in directory hierarchy which is just a way to execute
queries on real-names. But some paths do correspond to real-names and
same do not? I, personally, would be very wary to use such a behavior as
a fundamental model of file system.
Also, if directories are just queries, it is not clear why they have
real-names on their own. For example, what does it mean, for object O1
(a directory) to have a real-name "/a/b", and to return ("c" -> O2) as a
part of query result, where O2 has only one name, viz. "/d/e"?
Basically, without some extra restrictions, your model doesn't provide
consistency between user visible paths, and hidden real-names, which
makes it not very useful in the practice, I am afraid.
> for /tmp/A/. If the shell was smart enough to normalize its path by
> asking the directory for its name, it would know that /tmp/A/B/C/A
> was /tmp/A.
/tmp/A/B/C/A may have other names beyond /tmp/A, which one to choose?
> But yes, a stupid program could be confused by the
> difference between names.
A _user_ will most definitely be confused, which is much more important.
[...]
>
> Moving an object with "mv" would change its name. Moving a top-level
> directory like /usr would require visiting every object starting
> with /usr and doing an edit. A compression scheme could be used where
> the most-used top-level directory names were replaced with lookup
> tables, then /usr could be renamed just once in the table.
Heh, you just invented good old directories, by the way.
[...]
>
> Yes. :-) It is radical, and the idea is taken from databases. I
> thought that seemed to be the direction Reiser filesystems were moving.
> In this scheme a name is just another bit of metadata and not
> first-class important information. The name-query directories would be
> there for traditional filesystem users and Unix compatibility. They
> would probably be virtual and dynamic, only being created when needed
> and only being persistent if assigned meta-data (extra names (links),
> non-default permission bits, etc) or for performance reasons (faster to
> load from cache than searching every file).
That latter bit, about making them persistent, is where the tr
Re: Reiserfsck 1300Gig failed with following error
On Wednesday 01 June 2005 10:47, Matthias Barremaecker wrote: > Hi, > > using reiserfsprogs-3.6.19 > > Here is the error and messages : ... > > > 2 directory entries were hashed with not set hash. > 731305 directory entries were hashed with "r5" hash. > "r5" hash is selected > Flushing..finished > Read blocks (but not data blocks) 313507947 > Leaves among those 439626 > - corrected leaves 46 > - leaves all contents of which could not be > saved and deleted 56 > pointers in indirect items to wrong area 3997 (zeroed) > Objectids found 731997 > > Pass 1 (will try to insert 439570 leaves): > ### Pass 1 ### > Looking for allocable blocks .. finished > 0%20%40%pass1.c 212 balance_condition_2_fails > balance_condition_2_fails: block 1288402, pointer 168: The left > delimiting key [1412453424 1412453424 0x10001000 ??? (15)] of the block > (170046457) is wrong,the item cannot be found the key (which is in the tree already and supposed to be correct) is completely corrupted, no one key component is correct. data could be corrupted in the memory or on read/write -- bad cable, controller, dying harddrive, etc. > > Anyone any suggestions ? running fsck with the list of bad blocks is useful when you have the known fixed number of bad blocks, you know that the number will not change soon, in other words other blocks are relable. first of all you even have not complete badblocks run, so you cannot be sure you know the full bad block list. and the second, if your hardware is dying you need to fix it before running fsck on it. -- Thanks, Vitaly Fertman
