Re: [reiserfs-list] df diffs after backup/restore+reinstall of some RPMs
Manuel Krause wrote: > > On 07/29/2001 10:45 PM, Hans Reiser wrote: > > > Manuel Krause wrote: > >>On 07/27/2001 12:38 PM, Nikita Danilov wrote: > >>>Manuel Krause writes: > >>> > Hi! > >>> > > >>> > I keep backup+mkreiserfs+restoring my one root partition from time to > >>> > time. I _always_ mount the partitions -o noatime,notail. And usually get > >>> > df differences at least after final reboot. It usually grows by about 65 > >>> > MB. > >>> > > >>> > When reinstalling some actual/updated RPMs from SuSE for XF86 4.1.0 and > >>> > KDE2.1 via yast, my partition shows about 65MB freed even after repeated > >>> > reboot or longer uptime/useage afterwards. It's not related to log > >>> > files' appends or caches' growth (it's within the "about" ;-) ). > >>> > > >>> > Yesterday after a recent backup+ I reinstalled the RPMs their files I > >>> > had on disk already (to let the same files having on disk beeing > >>> > rewritten again). And got the same behavour of "shrinking". After that > >>> > it mostly always looked like: > >>> > > >>> > Filesystem 1k-blocks Used Available Use% Mounted on > >>> > /dev/hda7 2377508 1650340727168 70% / > >>> > (just to show some stats/relations...) > >>> > > >>> > So the growth/shrinking makes about 2.8% of the allocated blocks. > >>> > >>>I am not sure I understood you correctly, but may be this is just due to > >>>sub-optimal tree packing: reiserfs stores all meta-data (and files > >>>"tails") into balanced tree. For efficiency this tree is not always > >>>absolutely packed, that is, tree nodes are not stuffed with data > >>>completely. Actual packing depends on dynamic access pattern and can > >>>change. > >>> > >>Don't know what got unclear...?! (You may want to point me to it...!) > >> > >>Mmmh, so it really makes a difference in the "dynamic access pattern" if > >>I reinstalled via "rpm" instead of copying via "cp -a" ? When I mount > >>the partition "notail" files' tails don't get packed into balanced tree, > >>but metadata does. And that is/maybe a part of the actually > >>rpm-installed/re-written packages (in this case) ?! > >> > >>Ok, you really do know reiserfs better than me... :-) I'll take it for > >>normal reiserfs behaviour from now on. > >> > > > > Which was tighter packed, the cp -a or the RPM? > > > > It makes a difference in how tightly we can pack whether when inserting files > > you always insert in the order they will be stored in. > > > > Hans > > > > The reinstalled RPMs were tighter packed after cp -a of that partition. > > ;-) Sorry, you got me. I surely didn't get all of your last sentences > "complex" sense... > > For this test there was no "always"-condition. In the meaning: I copied > it from a "backup" partition and reinstalled the RPMs that were > installed before, just after cp -a and the reboot to this / partition. > > Best wishes, > > Manuel Hmmm, I don't understand your last sentence:-) If you do a cp -a, then you copy your files into the partition in the order in which reiserfs stores them. This makes our packing more efficient, because we don't have to deal with random insertions. Hans
Re: [reiserfs-list] 2.4.7+unlink...patch+vmware crashes+errors (was:Re: [reiserfs-list] Kernel 2.4.7 Released! Any Updates?)
On Sun, 29 Jul 2001, Vladimir V.Saveliev wrote: > The uncompleted unlinks do not get completed on mount time when > filesystem is mounted read-only. How does that filesystem get mounted > in your case? Seemingly (from Manuels mails) it doesn't unlink either on mount -o remount,rw. If that's right will it be fixed? (There is the possibility of unlinking already on readonly mount but we don't want to go through the discussion again of what's acceptable to change on mount ro, do we? :-) Otherwise this feature cannot be used on root filesystems which would be a shame. Robert -- Robert Casties - http://philoscience.unibe.ch/~casties History & Philosophy of Science Tel: +41/31/631-8505 Room: 216 Institute for Exact Sciences Sidlerstrasse 5, CH-3012 Bern Uni Bern(PGP key on homepage: D7 2B DE 64 2D 65 16 A0)
Re: [reiserfs-list] 2.4.7+unlink...patch+vmware crashes+errors (was:Re: [reiserfs-list] Kernel 2.4.7 Released! Any Updates?)
Robert Casties wrote: > On Sun, 29 Jul 2001, Vladimir V.Saveliev wrote: > > > The uncompleted unlinks do not get completed on mount time when > > filesystem is mounted read-only. How does that filesystem get mounted > > in your case? > > Seemingly (from Manuels mails) it doesn't unlink either on mount -o > remount,rw. If that's right will it be fixed? > (There is the possibility of unlinking already on readonly mount but we > don't want to go through the discussion again of what's acceptable to > change on mount ro, do we? :-) > > Otherwise this feature cannot be used on root filesystems which would be a > shame. > Yes, this is a bug and it will be fixed. Completion of things which were not completed in last session is a kind of consistency recovering so, I think we just have to do that together with journal replay regardless to how does filesystem get mounted. Thanks, vs
Re: [reiserfs-list] 2.4.7+unlink...patch+vmware crashes+errors (was: Re: [reiserfs-list] Kernel 2.4.7 Released! Any Updates?)
Manuel Krause wrote: > > Of course, since SuSE's original setup for ext2 partitions I have a line > "read-only" /etc/lilo.conf and in my /etc/fstab: > > /dev/hda7 / reiserfs defaults,noatime,notail 1 1 > > I assume, both ones are causing this read-only mount?! (There was a post > regarding the numbers to choose for reiserfs in fstab recently - IIRC?) > > So, in fact it mounts "/" read-only for the first time. But, it gets rw > afterwards. > > If I understood you correctly: The first time after "this poweroff" the > partition has to be mounted rw in order to complete the unlinks? > The uncompleted unlinks I have on disk will stay until next --rebuild-tree? > > I would be glad, if you could comment this mail. > No, you found another bug in the patch. I am testing the fix right now. Thanks, vs > > Thank you, I'll check it out now! > > Manuel
Re: [reiserfs-list] fsync(dir)
KF> Hi.
KF> Having experienced the (not unexpected) heavy slowdown one gets by
KF> fsyncing the directory after a rename/link/unlink/symlink operation, I
KF> have a question. When I do:
KF> fd=open(".");
KF> fsync(fd);
KF> close(fd);
KF> /* I do error checking, in case you were wondering :) */
KF> let's say "." has some hundred thousand files. Then this directory gets
KF> pretty huge. How much of it is written to disk when I fsync it? All of it,
KF> or only the dirty parts? And if only the dirty parts are written, how much
KF> is that? Can this be optimised?
fs/reiserfs/dir.c :
int reiserfs_dir_fsync(struct file *filp, struct dentry *dentry, int datasync) {
int ret = 0 ;
int windex ;
struct reiserfs_transaction_handle th ;
lock_kernel();
journal_begin(&th, dentry->d_inode->i_sb, 1) ;
windex = push_journal_writer("dir_fsync") ;
reiserfs_prepare_for_journal(th.t_super, SB_BUFFER_WITH_SB(th.t_super), 1) ;
journal_mark_dirty(&th, dentry->d_inode->i_sb, SB_BUFFER_WITH_SB
(dentry->d_inode->i_sb)) ;
pop_journal_writer(windex) ;
journal_end_sync(&th, dentry->d_inode->i_sb, 1) ;
unlock_kernel();
return ret ;
}
fs/reiserfs/journal.c:
int journal_end_sync(struct reiserfs_transaction_handle *th, struct super_block
*p_s_sb, unsigned long nblocks) {
return do_journal_end(th, p_s_sb, nblocks, COMMIT_NOW | WAIT) ;
}
As you see reiserfs_dir_fsync does transaction commit and waits until
it is done. In short, all modified metadata blocks are being written
to disk.
Reiserfs works fast if can join many logical transactions into one and
commit that huge transaction once. If reiserfs does many commits
(application often calls dir_fsync, for example) for small
transactions it slows reiserfs.
--
Thanks,
Alex.
Re: [reiserfs-list] 2.4.7+unlink...patch+vmware crashes+errors (was: Re: [reiserfs-list] Kernel 2.4.7 Released! Any Updates?)
Hi
Manuel Krause wrote:
> If I understood you correctly: The first time after "this poweroff" the
> partition has to be mounted rw in order to complete the unlinks?
> The uncompleted unlinks I have on disk will stay until next --rebuild-tree?
Ok, would you like to try the attached patch?
The
ftp.namesys.com/pub/reiserfs-for-2.4/2.4.7.pending/2.4.7-unlink-truncate-rename-rmdir.dif.bz2
is
updated as well.
Thanks,
vs
--- super.c~Sat Jul 28 20:20:09 2001
+++ super.c Mon Jul 30 15:03:11 2001
@@ -859,6 +859,9 @@
goto error ;
}
+/* look for files which were to be removed in previous session */
+finish_unfinished (s);
+
if (replay_only (s))
goto error;
@@ -920,10 +923,7 @@
journal_mark_dirty(&th, s, SB_BUFFER_WITH_SB (s));
journal_end(&th, s, 1) ;
-
- /* look for files which were to be removed in previous session */
- finish_unfinished (s);
-
+
s->s_dirt = 0;
} else {
struct reiserfs_super_block * rs = SB_DISK_SUPER_BLOCK (s);
Re: [reiserfs-list] fsync(dir)
On Mon, 30 Jul 2001, Alexander Zarochentcev wrote: > As you see reiserfs_dir_fsync does transaction commit and waits until > it is done. In short, all modified metadata blocks are being written > to disk. > > Reiserfs works fast if can join many logical transactions into one and > commit that huge transaction once. If reiserfs does many commits > (application often calls dir_fsync, for example) for small > transactions it slows reiserfs. Hi Alex. Thanks for your reply. My understanding of how this works is getting a bit better now :) But I need to acknowledge one small file written to disk at a time, sort of like in a mail system. Since I need to guarantee that the file is there, metadata and data, I fsync(tmpfile), rename(tmpfile,file) and fsync(dir) for every file, I was wondering if the entire directory is written every time, or perhaps just the one block that contains the difference from last time, if it is possible to separate this out. I was hoping it would be possible to make it run a bit faster. I hope this wasn't all too obvious from the mail you sent, but I couldn't make it out. :-) Ketil
[reiserfs-list] badBlocks
Hello reiserfs-list-info, I am running a Suse 7.2 Distribution out of the box. It comes with a running reiserfs module. My hard disk seems to have some badblocks. I tried already a low level format some weeks ago, but they come back again :-( No I read in the FAQ the article about error handling with bad blocks. Is they a way to do it with my Suse 7.2 System ? I guess that the add-bad-block command is part of the patch, isn't ? What is the best way to handle those problems ? cu stonki -- Wenn Du einen langen Tunnel siehst: Halt Dich vom Licht fern...
Re: [reiserfs-list] fsync(dir)
KF> On Mon, 30 Jul 2001, Alexander Zarochentcev wrote: >> As you see reiserfs_dir_fsync does transaction commit and waits until >> it is done. In short, all modified metadata blocks are being written >> to disk. >> >> Reiserfs works fast if can join many logical transactions into one and >> commit that huge transaction once. If reiserfs does many commits >> (application often calls dir_fsync, for example) for small >> transactions it slows reiserfs. KF> Hi Alex. KF> Thanks for your reply. My understanding of how this works is getting a bit KF> better now :) But I need to acknowledge one small file written to disk at KF> a time, sort of like in a mail system. Since I need to guarantee that the KF> file is there, metadata and data, I fsync(tmpfile), rename(tmpfile,file) KF> and fsync(dir) for every file, I was wondering if the entire directory is KF> written every time, or perhaps just the one block that contains the KF> difference from last time, if it is possible to separate this out. Reiserfs does not write entire directory, only blocks contain modified data. KF> I was KF> hoping it would be possible to make it run a bit faster. KF> I hope this wasn't all too obvious from the mail you sent, but I couldn't KF> make it out. :-) KF> Ketil -- Thanks, Alex.
Re: [reiserfs-list] 2.4.7+unlink...patch+vmware crashes+errors (was: Re: [reiserfs-list] Kernel 2.4.7 Released! Any Updates?)
On 07/30/2001 02:01 PM, Vladimir V.Saveliev wrote: > Hi > > Manuel Krause wrote: > > >>If I understood you correctly: The first time after "this poweroff" the >>partition has to be mounted rw in order to complete the unlinks? >>The uncompleted unlinks I have on disk will stay until next --rebuild-tree? >> > > Ok, would you like to try the attached patch? > The >ftp.namesys.com/pub/reiserfs-for-2.4/2.4.7.pending/2.4.7-unlink-truncate-rename-rmdir.dif.bz2 > is > updated as well. > > Thanks, > vs > [PATCH] Hi! And thanks again! I took the updated .bz2 from namesys. And I tested the poweroff with running vmware. Before that I changed back my lilo.conf to read-only mount the root partition. It works! My /var/log/boot.msg shows the following during next bootup: <4>reiserfs: checking transaction log (device 03:07) ... <4>Warning, log replay starting on readonly filesystem <4>reiserfs: replayed 19 transactions in 3 seconds <4>Removing [25349 39257 0x0 SD]..<4>done <4>Removing [25349 7437 0x0 SD]..<4>done <4>Removing [25349 7357 0x0 SD]..<4>done <4>There were 3 uncompleted unlinks/truncates. Completed <4>Using r5 hash to sort names <4>ReiserFS version 3.6.25 <4>VFS: Mounted root (reiserfs filesystem) readonly. Yes, and disk space is freed. Thank you! Manuel
Re: [reiserfs-list] 2.4.7+unlink...patch+vmware crashes+errors (was: Re: [reiserfs-list] Kernel 2.4.7 Released! Any Updates?)
On 07/30/2001 05:40 PM, Manuel Krause wrote: > On 07/30/2001 02:01 PM, Vladimir V.Saveliev wrote: > >> Hi >> >> Manuel Krause wrote: >> >>> If I understood you correctly: The first time after "this poweroff" the >>> partition has to be mounted rw in order to complete the unlinks? >>> The uncompleted unlinks I have on disk will stay until next >>> --rebuild-tree? >>> >> >> Ok, would you like to try the attached patch? >> The >> >ftp.namesys.com/pub/reiserfs-for-2.4/2.4.7.pending/2.4.7-unlink-truncate-rename-rmdir.dif.bz2 > >> is >> updated as well. >> >> Thanks, >> vs >> > > [PATCH] > > Hi! > > And thanks again! I took the updated .bz2 from namesys. And I tested the > poweroff with running vmware. Before that I changed back my lilo.conf to > read-only mount the root partition. It works! > > My /var/log/boot.msg shows the following during next bootup: > > <4>reiserfs: checking transaction log (device 03:07) ... > <4>Warning, log replay starting on readonly filesystem > <4>reiserfs: replayed 19 transactions in 3 seconds > <4>Removing [25349 39257 0x0 SD]..<4>done > <4>Removing [25349 7437 0x0 SD]..<4>done > <4>Removing [25349 7357 0x0 SD]..<4>done > <4>There were 3 uncompleted unlinks/truncates. Completed > <4>Using r5 hash to sort names > <4>ReiserFS version 3.6.25 > <4>VFS: Mounted root (reiserfs filesystem) readonly. > > Yes, and disk space is freed. > > Thank you! > > Manuel > The first time vmware accesses the disk after this reboot my /var/log/messages shows a line: Jul 30 17:41:22 firehead kernel: vs-: reiserfs_get_block: [25349 39253 0x80bd001 UNKNOWN] should not be found<7> After another reboot it doesn't show up any more when running vmware. I hope this won't cause problems? Thanks, Manuel
Re: [reiserfs-list] 2.4.7+unlink...patch+vmware crashes+errors (was: Re: [reiserfs-list] Kernel 2.4.7 Released! Any Updates?)
Manuel Krause wrote: > > On 07/30/2001 02:01 PM, Vladimir V.Saveliev wrote: > > > Hi > > > > Manuel Krause wrote: > > > > > >>If I understood you correctly: The first time after "this poweroff" the > >>partition has to be mounted rw in order to complete the unlinks? > >>The uncompleted unlinks I have on disk will stay until next --rebuild-tree? > >> > > > > Ok, would you like to try the attached patch? > > The >ftp.namesys.com/pub/reiserfs-for-2.4/2.4.7.pending/2.4.7-unlink-truncate-rename-rmdir.dif.bz2 > is > > updated as well. > > > > Thanks, > > vs > > > > [PATCH] > > Hi! > > And thanks again! I took the updated .bz2 from namesys. And I tested the > poweroff with running vmware. Before that I changed back my lilo.conf to > read-only mount the root partition. It works! > > My /var/log/boot.msg shows the following during next bootup: > > <4>reiserfs: checking transaction log (device 03:07) ... > <4>Warning, log replay starting on readonly filesystem > <4>reiserfs: replayed 19 transactions in 3 seconds > <4>Removing [25349 39257 0x0 SD]..<4>done > <4>Removing [25349 7437 0x0 SD]..<4>done > <4>Removing [25349 7357 0x0 SD]..<4>done > <4>There were 3 uncompleted unlinks/truncates. Completed > <4>Using r5 hash to sort names > <4>ReiserFS version 3.6.25 > <4>VFS: Mounted root (reiserfs filesystem) readonly. > > Yes, and disk space is freed. > > Thank you! > > Manuel Manuel, thanks for working with us on this all the way through to a complete solution for all users. It helps us a lot to have persons making as much effort to test things thoroughly as you have. Hans
Re: [reiserfs-list] badBlocks
Hi Stefan Onken wrote: > Hello reiserfs-list-info, > > I am running a Suse 7.2 Distribution out of the box. It comes > with a running reiserfs module. > > My hard disk seems to have some badblocks. I tried already a low > level format some weeks ago, but they come back again :-( > > No I read in the FAQ the article about error handling with bad > blocks. Is they a way to do it with my Suse 7.2 System ? I guess > that the add-bad-block command is part of the patch, isn't ? > No, this is a special program. http://www.namesys.com/add-bad-block.c > > What is the best way to handle those problems ? > This is the only way so far - so it is the best one. Although, it would be better if you found better harddrive. Thanks, vs
