[reiserfs-list] spam on the mailing list
Would it be possible to semi-close the mailing list so that subscribers can submit as normal, and non-subscribers must confirm their submission with a confirmation code that is sent back to them before it is accepted? Can the mailing list software even do this? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
[reiserfs-list] remounting r/o with mapped and deleted files
When a file is memory mapped into a process space (e.g. executable, library, data, etc), and deleted, the data blocks for that file must still remain reserved so they can be swapped in as needed. If the filesystem is then remounted r/o, there is a conflict. In ext2, this is resolved by disallowing the remount r/o in much the same way as disallowing an unmount when anything is mapped or open. I find this doesn't happen with reiserfs. So I am concerned. What I'd like to know is whether or not reiserfs is really doing this because it can handle the situation correctly, or if this is a bug. Consider the sequence of events: 1. A program maps in a dynamic library from a reiserfs filesystem 2. The filesystem is remounted read/only 3. The program exits leaving no more references to the deleted file 4. The filesystem remounted read/write Is the space for the deleted file now available? Consider a slightly different sequence of events: 4. The system is gracefully shutdown while that filesystem is read/only Or consider even this slightly different sequence of events: 4. The system is hard reset while that filesystem is read/only At some point, the data blocks for that deleted file must be recovered. In the third sequence, the most difficult, the only opportunity I see for this to happen is that during the original unlink when the on-disk reference count (not including in-kernel-only references, such as a process mapping), the fact of this delete was written into a special journal that would NOT be played out yet (because it's not yet time to actually clean out the blocks), but finally had to be played out later when the system comes back up and the filesystem is remounted. So how does reiserfs do this? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
[reiserfs-list] DNS server reading directly from reiserfs
Continuing from an earlier discussion I had regarding the use of reiserfs based files in place of databases, I was thinking about the issues involved in serving DNS data directly from files. The concern I had previously was the performance hit from open(),read(),close() to access a single piece of data to answer a query. Today I realized that DJBDNS uses the CDB format and does an open(),read(),close() sequence for each query as well. So it can't be that bad. This would come down to reiserfs vs CDB for which is the faster in finding the desired piece of data, not the syscall interfaces, in terms of comparing these two. Assuming all data is in a single directory, or maybe is in a directory tree structured TLD-first, what performance level might one expect doing this? With ext2 it could be quite costly due to the O(N) lookup. With reiserfs tree structure, this would be a lot better. And with tail-packing, less RAM would be needed to keep lots of data in cache for large servers. Any thoughts or benchmark data along these lines? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
Re: [reiserfs-list] copying partition to partition, sector by sector, live
On Mon, Apr 22, 2002 at 11:47:55PM +0100, Matthew Toseland wrote: | On Sun, Apr 21, 2002 at 08:39:55PM -0500, Phil Howard wrote: | On Mon, Apr 22, 2002 at 02:07:33AM +0100, Matthew Toseland wrote: | | | Ummm, LVM snapshots? (man lvcreate). | | No. Nothing to do with LVM. | I was suggesting a solution. Your problem is that reiserfs's metadata is | so dynamic that if you copy the partition while it is active, you end up | with metadata loss, which has to be fixed by reiserfsck. A possible | solution is to get a consistent snapshot. To do this, do: | | lvcreate -n snapshotname -L 500M -v /dev/vgname/partition name | dd if=/dev/vgname/snapshotname of=/usr/local/temp/snapshot.img bs=1M | lvremove -f /dev/vgname/snapshotname | | (1) 500M could be anything; it is the amount of space needed to log all | changes to the partition while the dd is going on; you can extend it later | but once it fills up completely, you're scr00d; presumably the dd will | return an error Sounds like journaling at the sector level. How does all that change get replayed after the snapshot is done? I'm starting to think it might be better to go back to using rsync on mounted filesystems. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
Re: [reiserfs-list] copying partition to partition, sector by sector, live
On Mon, Apr 22, 2002 at 02:58:34PM -0400, Chris Mason wrote: | On Sun, 2002-04-21 at 21:39, Phil Howard wrote: | On Mon, Apr 22, 2002 at 02:07:33AM +0100, Matthew Toseland wrote: | | | Ummm, LVM snapshots? (man lvcreate). | | No. Nothing to do with LVM. | | | Doing it safely will require something like lvm or evms snapshots. You | could do the sector by sector copy and then run reiserfsck | --rebuild-tree. The latest versions of reiserfsprogs are faster, the | speed relative to a search for updated files will depend on your data | set. | | More importantly you just don't get a consistent copy, regardless of the | FS you choose. I wouldn't consider a sector by sector copy on a mounted | FS a valid backup of any type of filesystem, especially not a tree based | one. I've never have a problem doing this with ext2 filesystems. By comparison I have had ext2 filesystems totally corrupted by just a power-reset. But I'm starting to think that with reiserfs, I need to go back to rsync as the backup mechanism. Some memory leak and stalling problems with rsync seem to be fixed, now. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
