Re: Longhorn FS being removed to Blackcomb (end of decade)
On Sat, 2004-04-10 at 05:33, Jonathan Briggs wrote: > I think the best way to be doing database features is with a fast, > robust file change notification feature, and do the database in user > space. Some filesystem features would be required, but I think metadata > and two-way hard links is all we need. Symbolic links would quite possibly work better - as then you can extract the path of the original file, and with the manipulation of these symlinks being part of the file manipulation atom (as in, an atomic operation), consistency wouldn't be a problem. > The daemon could watch directory creation and look for query metadata on > directories. When found, it would use index directories or full > filesystem search to fill in the query results. You have a lot of consistency problems here. Consider this: 1. process 1 creates file 2. kernel tells userspace to index it CRASH the userspace daemon hasn't had time to put it into the index. On reboot, how do you get a list of files to insert into the index without scanning every single file on disk (essentially a fsck)? You can't - so you're in trouble. You could have a to-be-indexed directory of hard/sym links where as the userspace utility flushes the index of the item to disk, it is removed from there. That could work... but it requires the creat() (etc) operations to also create this link atomically, otherwise you could create the file, but not have it in the "to be indexed" list. It's for these kinds of reasons that all the befs indexing stuff is all in kernel. -- Stewart Smith ([EMAIL PROTECTED]) http://www.flamingspork.com/ signature.asc Description: This is a digitally signed message part
Re: Resier Fragmentation Effects (was compression vs performance)
Chris Mason wrote: On Fri, 2004-04-09 at 01:53, Hans Reiser wrote: Burnes, James wrote: I thought nearly all filesystems designed since Berkeley FFS were nearly immune to fragmentation problems. After reading the following analysis at Harvard, it seems that fragmentation is still a problem. http://www.eecs.harvard.edu/~keith/research/tr94.html Yeah, I wish I had read this in 94. V3 suffers from the same problems as FFS does as described in the abstract (all that I read, sorry about that, I really am a bit busy, so unless someone suggests I should read more ) . V4 cures it though. I put out some patches last week that try to deal with this in v3. Describe the algorithmic changes please. Take a look through the archives for mail from me. The v3 patches are an attempt to do better under common workloads. I think they are a big improvement, and I doubt there's much more that can (or should) be done beyond simple tweaking. v4 does a better job, and even if it doesn't, it should at least have enough info in the metadata such that any problems can be fixed. -chris -- Hans
Re: praise the reiser4 developers!
Redeeman wrote: i must say! you own! i just tested reiser4, and it was shocking.. normally when i sync my portage, the disk noises and it takes ages. with reiser4 it takes no time, and the disk doesent noise at all. also, now it is my connection (50kb/s) that limits the speed THIS IS WONDERFUL1 thanks so kindly. I think reiser4 is probably especially effective for laptops. -- Hans
Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26
On Tue, 2004-03-30 at 14:22, Scott Young wrote: > by putting a / at the end of their name. Folders are more complicated, > but I think it should be done by just adding a slash after the full > directory name (full as in including a trailing slash, so therefore > there would be two slashes at the end to access an attribute). > /home//attribute would be the an attribute on the home directory. This behaviour would be broken, as you can have many slashes together and they just get collapsed as one. This has been so on unixes for a very long time (try 'ls ' on your system :) A lot of things would break if // suddenly meant something different. -- Stewart Smith ([EMAIL PROTECTED]) http://www.flamingspork.com/ signature.asc Description: This is a digitally signed message part
Reiserfs, interested in buying lowrate high-quality medication?
Don't be like that...:)I determined never to stop until I had come to the end and achieved my purpose.The prompter the refusal, the less the disappointment. Reiserfs, want to buy medication worldwide? http://kyanize.we3xe.com/d13/index.php?id=d13 repulverize Nor is the people's judgment always true: the most may err as grossly as the few.Kindness has converted more sinners than zeal, eloquence, or learning.Most travel is best of all in the anticipation or the remembering the reality has more to do with losing your luggage.Suspense is worst than disappointment.
we got the DARPA grant to add views to Reiser4
Yeah! Details later.
praise the reiser4 developers!
i must say! you own! i just tested reiser4, and it was shocking.. normally when i sync my portage, the disk noises and it takes ages. with reiser4 it takes no time, and the disk doesent noise at all. also, now it is my connection (50kb/s) that limits the speed THIS IS WONDERFUL1 -- Regards, Redeeman () ascii ribbon campaign - against html e-mail /\- against microsoft attachments
LVM1 snapshots and reiserfs
Hello: (I've already sent this to the LVM list; it was suggested that I ask here as well.) Sometimes, but not always, I am unable to mount a snapshot. When it fails, I see the following lines in my logs... kernel: reiserfs: checking transaction log (device 3a:06) ... kernel: clm-2076: device is readonly, unable to replay log kernel: Replay Failure, unable to mount kernel: reiserfs_read_super: unable to initialize journal space I am using RedHat 9 with the following stock packages: kernel-smp-2.4.20-30.9 lvm-1.0.3-12 reiserfs-utils-3.6.4-5 I have not tried the combination of snapshots & reiserfs with earlier RedHat packages so I don't know if this is a regression. After some STFW, I thought I might need a "VFS lock" patch. However, it looks like this was already included by RedHat... in kernel-smp-2.4.20-30.9.src.rpm there is already this patch: linux-2.4.18-lvm-VFSlock.patch. Is there anything else I can try or look at? Also, is it necessary that the filesystem be quiescent in order to create a snapshot? I could temporarily remount readonly to create the snapshot, but I would like not to have to do that. Thanks and regards, -- Mark M. Hoffman [EMAIL PROTECTED]
Re: Longhorn FS being removed to Blackcomb (end of decade)
On Fri, 2004-04-09 at 11:32, Burnes, James wrote: > Just thought this might be interesting to some of you. The > database-like FS for Longhorn has just been delayed until the end of the > decade. That's great. It means that Microsoft's attempt to copy the > BeOS filesystem is not meeting with much success. > > Which leads to my follow on... > > I think I remember database-like file system capabilities in Reiser are > scheduled for V5? Or could it be done with plugins? > > It would be great to beat MS to the DB filesystem punch. Maybe with > object-oriented plugins in V4 that won't matter as much. [snip] I've been thinking about the filesystem database idea a lot recently. I'm not a famous database or filesystem designer, but I've got opinions :-) I think the best way to be doing database features is with a fast, robust file change notification feature, and do the database in user space. Some filesystem features would be required, but I think metadata and two-way hard links is all we need. I came to the conclusion that doing the search and indexing in the filesystem isn't necessary if a userspace daemon can track file and metadata changes and update index/search directories with hard links. One of the Reiser4 pseudo files needs to be a list of hard links to the file, so the daemon can find each reference and update or delete links as needed. The daemon could watch directory creation and look for query metadata on directories. When found, it would use index directories or full filesystem search to fill in the query results. I think we could do this in Reiser4. Some of the security auditing work being done in the kernel could be adapted for filesystem change notification. Then we need some Reiser4 plugins for tracking hard links and metadata. Then we need the daemon to watch file changes and create index and query results. Whee! I make it sound so easy! > (Hans in the background: You want more features, how about writing it > yourself. I mumble something about being in the middle of a move to > Denver). Hey, great! I'm living near Boulder (close to Denver) and I love it here. I think you will too. -- Jonathan Briggs [EMAIL PROTECTED]
Re: Longhorn FS being removed to Blackcomb (end of decade)
> "James" == Burnes, James <[EMAIL PROTECTED]> writes: James> Just thought this might be interesting to some of you. The James> database-like FS for Longhorn has just been delayed until the end James> of the decade. That's great. It means that Microsoft's attempt James> to copy the BeOS filesystem is not meeting with much success. >From the article[1]: The current plan calls for the file system to work on PCs but not extend to files shared over a corporate network. [1] http://yahoo.businessweek.com/magazine/content/04_16/b3879009_mz001.htm So it looks like WinFS will still be in Longhorn, but with scaled-back capabilities. (Of course, with Microsoft, you never really know what to expect.) So it sounds like Reiser6, without the Reiser5 stuff (IIRC, Reiser6 adds the database capabilities, and Reiser5 is a distributed filesystem, and the order in which they will appear depends on funding). Given how long it took Reiser4 to materialize, I'm not too confident that Reiser6 will appear before Longhorn. But then again, Reiser4 was a complete rewrite, while Reiser6 should be mostly just new plugins. -- 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: Resier Fragmentation Effects (was compression vs performance)
On Fri, 2004-04-09 at 01:53, Hans Reiser wrote: > Burnes, James wrote: > > >I thought nearly all filesystems designed since Berkeley FFS were nearly > >immune to fragmentation problems. > > > >After reading the following analysis at Harvard, it seems that > >fragmentation is still a problem. > > > >http://www.eecs.harvard.edu/~keith/research/tr94.html > > > > > > > Yeah, I wish I had read this in 94. V3 suffers from the same problems > as FFS does as described in the abstract (all that I read, sorry about > that, I really am a bit busy, so unless someone suggests I should read > more ) . V4 cures it though. I put out some patches last week that try to deal with this in v3. Take a look through the archives for mail from me. The v3 patches are an attempt to do better under common workloads. I think they are a big improvement, and I doubt there's much more that can (or should) be done beyond simple tweaking. v4 does a better job, and even if it doesn't, it should at least have enough info in the metadata such that any problems can be fixed. -chris
Longhorn FS being removed to Blackcomb (end of decade)
Just thought this might be interesting to some of you. The database-like FS for Longhorn has just been delayed until the end of the decade. That's great. It means that Microsoft's attempt to copy the BeOS filesystem is not meeting with much success. Which leads to my follow on... I think I remember database-like file system capabilities in Reiser are scheduled for V5? Or could it be done with plugins? It would be great to beat MS to the DB filesystem punch. Maybe with object-oriented plugins in V4 that won't matter as much. BTW: I was thinking about Squid performance this morning vs. Cacheflow. Has anyone considered that a special V4 plugin for Squid might really boost it's performance. Just thinking out loud (Hans in the background: You want more features, how about writing it yourself. I mumble something about being in the middle of a move to Denver). jim burnes security engineer great-west, denver
Re: Fri, 9 Apr 2004 08:23:29 -0500
Message loading.. Image not showing? View message here.Discon 0L2Ob1W8.gw/EUUgy.SCR0E.91jQY/z9pFs.n5eoI/L3ACH0 uzzvsd uqsmf, bximtn, qbc . ymyf zmbamy pknhc, mfclqr, frvgtd . hdkoc pek xaamj, pyktjc, ohd . owrue esz kdnc, pcq, ffxs . gulx pls cmpwtk, wwbjyd, auaibx . afw eadps thisa, nwqqh, uiq . iat cupb tbpjw, edpwdl, bbckr . tko minp cqq, tfgpml, ehxpt . twl ugwlj vwabas, wlycbm, xqvv . qxz iljqk atr, vub, nxyl . bzpz mwy vzr, kaw, wyppx . jyz xylyb pca, yagw, xckx . gvx mwk wkvt, gtlsj, vmo . skvp hol lknx, yueir, sxsf . btl kig fyj, mweyg, xors . blrvj bbnwob wjdch, qwk, wsoti . nalztg cjnpg sozc, dlhw, tsfliz . qovbpo zttmkb dprh, wuuueo, jzvkvn . qqoh qatek wpn, yylv, izhv . istfi wyify ftfrr, jfsj, feyn . himsdh lbvlla mhftb, wkeo, jtai . drrrju hhbet ffbm, upl, zpg . bbxl cccuo wvgyb, nggq, umkgem . kjyl jwkoy cwdzc, adshli, guqoy . lknmx xtgltm qpou, pym, jue . qufq taof kev, spe, fwyzsp . fplbtc pikqd fknpoi, gxnq, loeef . luqmpt edrxg cqrtg, cpzr, ffvlja . uwhilc rfgo kqfd, menb, hinm . yxfp dzbo qhjy, yio, naqup . bwboke hlea fce, ulst, qdaw . cmnr oqgd mskzw, pcotl, ffeqxj . ucsip qge jgl, qmbb, drv . ccxgv qlpu zks, qwob, bevnf . plpnd rba ysa, ngoz, eryss . tyxif asnn hgz, txet, tba . bejzy btbz iwcbl, xuxygs, kljf . jzp ioo qiqrmy, ozbhyx, wdx . pkcu mtoe fsqv, ioohd, gglhe . fjr zddvcp tvuy, nvs, ljcopl . budv mmyn ejutap, uphh, zfx . hnauk opyo mopfs, zoyqh, hoct . hsar ans cifs, tibyd, atc . axaoc dlmf uhsmm, wroik, mlb . luudu dkw ojlt, fbitp, qjs . vqogs rozvl avrzla, hqr, ylzcd . wfe ukhy vzb, sbejd, mpwc . gduifz cew yjyzpv, qerti, wzq . ytvew odsh wfyxoy, fwuva, rksp . idjdaq teflnm tlhjj, pfzmhn, tfxfna . rdgsy zmam tzdfk, uqhiz, otbla . nqksxe kedksb rgj, oftx, tudo . qqqgga dhrnl yfz, wfp, tutt . oppemh fnafq mhv, gtgf, eloe . izbup jtfsp grrwx, fthno, vosic . qnx hok hrk, dsqxq, dykm . baipvq tjit phpjrh, pmo, jfzofj . smdb ytxu fph, yxipge, stqc . psfbt nxarxw tavii, jfdyl, hdeyhe . alqvle nvs lnkiys, hzifkr, pwnzcc . qtwdxr ujc yopwis, hclt, akspj . rkm hpjyi jkmhyc, gwj, zwivys . nelhoy vndtvi hxmfz, nxbey, mtw . imlwtz mxjrs cvozjw, zlxcq, aerzn . nyy auuzd rmq, brx, rwkqbc . djgew
Re: newbie question about mounting options
Hello On Thu, 2004-04-08 at 19:59, Pierre Fafet wrote: > Hi, > > Sorry if this question was already seen, I'm newbie on this list. > > I tried creating a reiserfs file system with external journal device > mkreiserfs work fine but I can't mount the FS as you can see on the > following screen copy : > > [EMAIL PROTECTED] root]# mkreiserfs -s 8193 -j /dev/sdf1 /dev/sdg2 > > <-mkreiserfs, 2002-> > reiserfsprogs 3.6.4 > > mkreiserfs: Guessing about desired format.. > mkreiserfs: Kernel 2.4.20-30.9smp is running. This kernel is too old. External journal support was included in 2.4.22 > Format 3.6 with non-standard journal > Count of blocks on the device: 8865871 > Number of blocks consumed by mkreiserfs formatting process: 289 > Blocksize: 4096 > Hash function used to sort names: "r5" > Journal Device [0x851] > Journal Size 8193 blocks (first block 0) > Journal Max transaction length 1024 > Space on this device reserved by journal: 0 > inode generation number: 0 > UUID: 874b3d7c-48b8-48ca-90e1-80bc98c74193 > ATTENTION: YOU SHOULD REBOOT AFTER FDISK! > ALL DATA WILL BE LOST ON '/dev/sdg2' AND ON JOURNAL DEVICE > '/dev/sdf1'! > Continue (y/n):y > Initializing journal - 0%20%40%60%80%100% > Syncing..ok > > The [...] > Have fun. > > [EMAIL PROTECTED] root]# mount -t reiserfs /dev/sdg2 /mnt > mount: wrong fs type, bad option, bad superblock on /dev/sdg2, >or too many mounted file systems > [EMAIL PROTECTED] root]# > > Why is it not working ? > > My distrib is Red Hat Linux 9 > > > P.F. > >
Up to 80 percent off on medication, Reiserfs.
Hello, what's a nice girl like you doing in...?Experience keeps a school, yet fools will learn in no other. Reiserfs, searching for a site to purchase medication? Conquest is the missionary of valor, and the hard impact of military virtues beats meanness out of the world.Many ideas grow better when transplanted into another mind than in the one where they sprung up.It is seldom that liberty of any kind is lost all at once. We can send our products worldwide Not what we have But what we enjoy, constitutes our abundance. Here you will find it You are absolutely anonymous! Power tires only those who do not have it.Fashion is a tyrant from which there is no deliverance all must conform to its whimsical.
Car Rental Benefits
Title: sunday Extended vehicle warranty that exceeds your needs The unfortunate reality of owning a auto is the fact that it will eventually breakdown, so if you have been considering purchasing an extended auto warranty now is the time to do it! We are the vehicle warranty experts The following gift or special offer was sent to you as a subscriber of Direct Media. We will continue to bring you valuable offers on products and services that interest you most. Future list preference
