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
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: 4reiserfs: checking transaction log (device 03:07) ... 4Warning, log replay starting on readonly filesystem 4reiserfs: replayed 19 transactions in 3 seconds 4Removing [25349 39257 0x0 SD]..4done 4Removing [25349 7437 0x0 SD]..4done 4Removing [25349 7357 0x0 SD]..4done 4There were 3 uncompleted unlinks/truncates. Completed 4Using r5 hash to sort names 4ReiserFS version 3.6.25 4VFS: 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: 4reiserfs: checking transaction log (device 03:07) ... 4Warning, log replay starting on readonly filesystem 4reiserfs: replayed 19 transactions in 3 seconds 4Removing [25349 39257 0x0 SD]..4done 4Removing [25349 7437 0x0 SD]..4done 4Removing [25349 7357 0x0 SD]..4done 4There were 3 uncompleted unlinks/truncates. Completed 4Using r5 hash to sort names 4ReiserFS version 3.6.25 4VFS: 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 found7 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] 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
