Re: RaiserFS via NFS
Hi Markus On 18.04.2004, at 12:30, Markus Oswald wrote: I suggest you read it first... Quote from NFS_README.html: --- # In order to have mailbox locking over NFS you have to configure # everything to use fcntl() locks for mailbox access (or switch to # maildir style, which needs no application-level lock controls). Ooops I stand corrected. Regards, Andrew
Re: RaiserFS via NFS
Hi Markus On 18.04.2004, at 12:30, Markus Oswald wrote: I suggest you read it first... Quote from NFS_README.html: --- # In order to have mailbox locking over NFS you have to configure # everything to use fcntl() locks for mailbox access (or switch to # maildir style, which needs no application-level lock controls). Ooops I stand corrected. Regards, Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
## Donovan Baarda ([EMAIL PROTECTED]): > In the case of Reiser vs JFS vs XFS vs ext3, it depends on what you > want. If you want stability and reliability, then maturity is what > counts. XFS and JFS have long histories, but not with Linux. ext3 is the > newest but is a relatively simple extension to the mature ext2. Reiser > was the first journaling filesystem to be included into the Linux > kernel, and has paved the way for all the others. Don't let the old > history of Reiser bugs put you off; that is a history of bugs found and > fixed. The others just haven't got much of a history yet... Perhaps we had just one reiser-related crash too much, but for now we are running fine on ext3 with the first xfs-(non-IRIX)-machines for not-that-critical applications. > I think they are all pretty much on par now. For me, inclusion into the > standard Linux kernel counts for something; others have already thought > hard about what is "ready" to go in, I don't have to duplicate that > effort. AFAIK raiser and ext3 are the only ones in so far. 2.4.26 has ext3, reiserfs, jfs and xfs. Regards, Christoph -- Spare Space
Re: RaiserFS via NFS
## Donovan Baarda ([EMAIL PROTECTED]): > In the case of Reiser vs JFS vs XFS vs ext3, it depends on what you > want. If you want stability and reliability, then maturity is what > counts. XFS and JFS have long histories, but not with Linux. ext3 is the > newest but is a relatively simple extension to the mature ext2. Reiser > was the first journaling filesystem to be included into the Linux > kernel, and has paved the way for all the others. Don't let the old > history of Reiser bugs put you off; that is a history of bugs found and > fixed. The others just haven't got much of a history yet... Perhaps we had just one reiser-related crash too much, but for now we are running fine on ext3 with the first xfs-(non-IRIX)-machines for not-that-critical applications. > I think they are all pretty much on par now. For me, inclusion into the > standard Linux kernel counts for something; others have already thought > hard about what is "ready" to go in, I don't have to duplicate that > effort. AFAIK raiser and ext3 are the only ones in so far. 2.4.26 has ext3, reiserfs, jfs and xfs. Regards, Christoph -- Spare Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Sun, 18 Apr 2004 02:51, Dan MacNeil <[EMAIL PROTECTED]> wrote: > I've just converted from mbox to maildir > > Right now there are some users with 500 files in a directory, I expect > this go grow. > > I expect this figure to grow. RaiserFS is looking good. ReiserFS is very good for maildir. For Maildir storage the average file size is often in the 10K-20K range, this means that there are a few megabyte+ files and many <4K files. ReiserFS uses a 4K block size, and for a file <16K in ReiserFS the last part of the file (known as the "tail") will be stored in a block with tails of other files. So for example you could have 4*900 byte files in one 4K block. This can significantly decrease disk space, for a Maildir system that will be close to 2K per file. The reduction in disk space will however come at the cost of increased CPU use, so if your CPU is slow then you may want to mount -o notails. But with the way CPUs have been getting faster that shouldn't be a problem. > The benefits of running a central storage server and a bunch of seperate > web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not > much more than NFS all connected with a cheap Gigbit switch are also > appealing to me. > > Is there any benefit to RaiserFS if I am accessing it via NFS ? Some years ago I did some Bonnie++ file creation tests on an AIX machine and found that a ReiserFS file system NFS mounted over 10baseT outperformed the local disk! Yes, ReiserFS offers definite benefits even over NFS. But in 2.6.x Ext3 uses directory hashing which significantly improves performance with many files in a directory, ReiserFS is no longer 30 times faster than Ext3 for file creation, maybe 4-5 times faster. But the NFS store is probably a bad idea. NFS isn't something you want to use for reliability. I suggest having some spamfiltering machines on the front-end which also direct the mail to the correct back-end server. Have POP, IMAP, and SMTP for delivery running on the machines with the mail store. Have webmail on entirely separate machines. Have LDAP servers to contain user-names, passwords, and the record of which server stores each user's mail. I've run a system like this with >200,000 mail boxes per server (Dell 2650 machines with 4G of RAM and 4 SCSI disks in a RAID-5 array). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: RaiserFS via NFS
On Sun, 18 Apr 2004 02:51, Dan MacNeil <[EMAIL PROTECTED]> wrote: > I've just converted from mbox to maildir > > Right now there are some users with 500 files in a directory, I expect > this go grow. > > I expect this figure to grow. RaiserFS is looking good. ReiserFS is very good for maildir. For Maildir storage the average file size is often in the 10K-20K range, this means that there are a few megabyte+ files and many <4K files. ReiserFS uses a 4K block size, and for a file <16K in ReiserFS the last part of the file (known as the "tail") will be stored in a block with tails of other files. So for example you could have 4*900 byte files in one 4K block. This can significantly decrease disk space, for a Maildir system that will be close to 2K per file. The reduction in disk space will however come at the cost of increased CPU use, so if your CPU is slow then you may want to mount -o notails. But with the way CPUs have been getting faster that shouldn't be a problem. > The benefits of running a central storage server and a bunch of seperate > web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not > much more than NFS all connected with a cheap Gigbit switch are also > appealing to me. > > Is there any benefit to RaiserFS if I am accessing it via NFS ? Some years ago I did some Bonnie++ file creation tests on an AIX machine and found that a ReiserFS file system NFS mounted over 10baseT outperformed the local disk! Yes, ReiserFS offers definite benefits even over NFS. But in 2.6.x Ext3 uses directory hashing which significantly improves performance with many files in a directory, ReiserFS is no longer 30 times faster than Ext3 for file creation, maybe 4-5 times faster. But the NFS store is probably a bad idea. NFS isn't something you want to use for reliability. I suggest having some spamfiltering machines on the front-end which also direct the mail to the correct back-end server. Have POP, IMAP, and SMTP for delivery running on the machines with the mail store. Have webmail on entirely separate machines. Have LDAP servers to contain user-names, passwords, and the record of which server stores each user's mail. I've run a system like this with >200,000 mail boxes per server (Dell 2650 machines with 4G of RAM and 4 SCSI disks in a RAID-5 array). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Donovan Baarda wrote: On Tue, 2004-04-20 at 05:07, Markus Schabel wrote: Marcel Hicking wrote: --Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: I chose ext3 for it's reliablity over ReiserFS. I found ext3 too slow (although rock solid) for large amounts of mail. Since Reiser was no option (too much data loss in the past) we opted for XFS. well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except How long ago? Was this a recent kernel/reiserfs-tools? 2.4.18 / stable - and on multiple different machines. backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). Sounds strange... have you mounted the squid partition with '-o noatime'? This is a standard recommendation for squid as it reads lots of little files and the updated atime writes can be a slowdown. yes. It sounds to me more like you have squid slowly running out of memory. Check 'free' before and after you restart squid. Depending on how you have configured your squid, it can start thrashing when the memory cache fills up. It could be that reiser uses a little more memory, pushing your squid over the edge. there's always plenty of free memory available (somewhere around 50 MB, and squid uses about 120 MB). the interesting thing is that the machine keeps slow if i restart squid immediatly, but if i wait a few minutes before starting again all is fine again. I remember reading a report that tested Linux/squid on a heap of different filesystems that concluded that the best was reiser... this was some time ago though so things might have changed, and perhaps the noatime was critical. well, as long as it runs with XFS without problems, i'll keep it that way ;) best regards, Markus -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows.
Re: RaiserFS via NFS
Donovan Baarda wrote: On Tue, 2004-04-20 at 05:07, Markus Schabel wrote: Marcel Hicking wrote: --Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: I chose ext3 for it's reliablity over ReiserFS. I found ext3 too slow (although rock solid) for large amounts of mail. Since Reiser was no option (too much data loss in the past) we opted for XFS. well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except How long ago? Was this a recent kernel/reiserfs-tools? 2.4.18 / stable - and on multiple different machines. backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). Sounds strange... have you mounted the squid partition with '-o noatime'? This is a standard recommendation for squid as it reads lots of little files and the updated atime writes can be a slowdown. yes. It sounds to me more like you have squid slowly running out of memory. Check 'free' before and after you restart squid. Depending on how you have configured your squid, it can start thrashing when the memory cache fills up. It could be that reiser uses a little more memory, pushing your squid over the edge. there's always plenty of free memory available (somewhere around 50 MB, and squid uses about 120 MB). the interesting thing is that the machine keeps slow if i restart squid immediatly, but if i wait a few minutes before starting again all is fine again. I remember reading a report that tested Linux/squid on a heap of different filesystems that concluded that the best was reiser... this was some time ago though so things might have changed, and perhaps the noatime was critical. well, as long as it runs with XFS without problems, i'll keep it that way ;) best regards, Markus -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Tue, 2004-04-20 at 05:07, Markus Schabel wrote: > Marcel Hicking wrote: > > --Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: > > > >>I chose ext3 for it's reliablity over ReiserFS. > > > > I found ext3 too slow (although rock solid) for large > > amounts of mail. Since Reiser was no option (too much > > data loss in the past) we opted for XFS. > > well, i see the same problem as everybody here: i've had some corrupted > reiserfs systems, and it wasn't possible to restore the data (except How long ago? Was this a recent kernel/reiserfs-tools? > backups of coures ;)). We're still running reiserfs on our proxy servers > (squid), but we have the phenomenon that the machines get slower and > slower while squid is running, and if you stop squid and wait some time > and start it again it all goes fine again. but the problem isn't squid, > it seems to be reiserfs which seems to be not able get all data written > to disk in time and slows the computer down. (sure this also depends on > the harddisks, but we played around with hdparm and the situation was > exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it > cannot be the HDD). Sounds strange... have you mounted the squid partition with '-o noatime'? This is a standard recommendation for squid as it reads lots of little files and the updated atime writes can be a slowdown. It sounds to me more like you have squid slowly running out of memory. Check 'free' before and after you restart squid. Depending on how you have configured your squid, it can start thrashing when the memory cache fills up. It could be that reiser uses a little more memory, pushing your squid over the edge. I remember reading a report that tested Linux/squid on a heap of different filesystems that concluded that the best was reiser... this was some time ago though so things might have changed, and perhaps the noatime was critical. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/
Re: RaiserFS via NFS
On Tuesday 20 April 2004 01:21, Markus Schabel wrote: > Jeremy Zawodny wrote: > > On Monday, April 19, 2004, at 03:07 PM, Markus Schabel wrote: > >> well, i see the same problem as everybody here: i've had some > >> corrupted reiserfs systems, and it wasn't possible to restore the > >> data (except backups of coures ;)). We're still running reiserfs on > >> our proxy servers (squid), but we have the phenomenon that the > >> machines get slower and slower while squid is running, and if you > >> stop squid and wait some time and start it again it all goes fine > >> again. but the problem isn't squid, it seems to be reiserfs which > >> seems to be not able get all data written to disk in time and slows > >> the computer down. (sure this also depends on the harddisks, but we > >> played around with hdparm and the situation was exactly the same > >> with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be > >> the HDD). For what it's worth: I've had opposite experiences. At one time I had what looked like severe filesystem corruption on my reiserfs disk. But it repaired it without any problems. I've been using it for at least 3 or 4 years now, on all my systems, ranging from laptops to a 0.4 TB raid5 fileserver and I am very happy with both the speed and the reliability. > > I'm confused. How does measuring sequential read/write performance > > map to squid performance? Doesn't squid usually do lots of little > > read/write ops, with lots of seeks too? > > well, the idea was to check if system performance would be influenced > by HDD speed. sure sequential read/write is not really the best test > for this, but i thougth we would see some changes, and since we didn't > the idea was that the HDD isn't the bottleneck. and since the system > behavior is better with ext3 than with reiserfs, the bottleneck may be > the filesystem. I think reiserfs is better than ext3 for lots of small files. Well, actually I think reiserfs is better but then again, I might be biased... ;-) > is it possible to log HDD access (e.g. open, close, read, write, seek, > etc. operations)? Sure. man iostat (package sysstat) (Or give bonnie a try if it is only for benchmarking) Maarten -- Linux: Because rebooting is for adding hardware.
Re: RaiserFS via NFS
On Tue, 2004-04-20 at 08:02, Christoph Moench-Tegeder wrote: > ## Jose Alberto Guzman ([EMAIL PROTECTED]): > > > One recomendation is to always use the latest reiserfs-tools from > > upstream in case of need, as the developers are constantly improving them. > > In case of emergency, I do not want to rely on the latest improvements > (always hoping that all necessary improvements have made their way > into the source...). If you search, you will find reported 'problems' for any of the latest journaling filesystems. All of the solutions for these problems are "use the latest" if you are lucky. If you are unlucky the solution is "will be fixed soon". Bare in mind when googling for problem reports that the oldest and/or most popular will have the most "hits", but this does not make them the "worst"... it often means they are the "best". In the case of Reiser vs JFS vs XFS vs ext3, it depends on what you want. If you want stability and reliability, then maturity is what counts. XFS and JFS have long histories, but not with Linux. ext3 is the newest but is a relatively simple extension to the mature ext2. Reiser was the first journaling filesystem to be included into the Linux kernel, and has paved the way for all the others. Don't let the old history of Reiser bugs put you off; that is a history of bugs found and fixed. The others just haven't got much of a history yet... I think they are all pretty much on par now. For me, inclusion into the standard Linux kernel counts for something; others have already thought hard about what is "ready" to go in, I don't have to duplicate that effort. AFAIK raiser and ext3 are the only ones in so far. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/
Re: RaiserFS via NFS
Jeremy Zawodny wrote: On Monday, April 19, 2004, at 03:07 PM, Markus Schabel wrote: well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). I'm confused. How does measuring sequential read/write performance map to squid performance? Doesn't squid usually do lots of little read/write ops, with lots of seeks too? well, the idea was to check if system performance would be influenced by HDD speed. sure sequential read/write is not really the best test for this, but i thougth we would see some changes, and since we didn't the idea was that the HDD isn't the bottleneck. and since the system behavior is better with ext3 than with reiserfs, the bottleneck may be the filesystem. is it possible to log HDD access (e.g. open, close, read, write, seek, etc. operations)? best regards -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows.
Re: RaiserFS via NFS
On Tue, 2004-04-20 at 05:07, Markus Schabel wrote: > Marcel Hicking wrote: > > --Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: > > > >>I chose ext3 for it's reliablity over ReiserFS. > > > > I found ext3 too slow (although rock solid) for large > > amounts of mail. Since Reiser was no option (too much > > data loss in the past) we opted for XFS. > > well, i see the same problem as everybody here: i've had some corrupted > reiserfs systems, and it wasn't possible to restore the data (except How long ago? Was this a recent kernel/reiserfs-tools? > backups of coures ;)). We're still running reiserfs on our proxy servers > (squid), but we have the phenomenon that the machines get slower and > slower while squid is running, and if you stop squid and wait some time > and start it again it all goes fine again. but the problem isn't squid, > it seems to be reiserfs which seems to be not able get all data written > to disk in time and slows the computer down. (sure this also depends on > the harddisks, but we played around with hdparm and the situation was > exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it > cannot be the HDD). Sounds strange... have you mounted the squid partition with '-o noatime'? This is a standard recommendation for squid as it reads lots of little files and the updated atime writes can be a slowdown. It sounds to me more like you have squid slowly running out of memory. Check 'free' before and after you restart squid. Depending on how you have configured your squid, it can start thrashing when the memory cache fills up. It could be that reiser uses a little more memory, pushing your squid over the edge. I remember reading a report that tested Linux/squid on a heap of different filesystems that concluded that the best was reiser... this was some time ago though so things might have changed, and perhaps the noatime was critical. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Tuesday 20 April 2004 01:21, Markus Schabel wrote: > Jeremy Zawodny wrote: > > On Monday, April 19, 2004, at 03:07 PM, Markus Schabel wrote: > >> well, i see the same problem as everybody here: i've had some > >> corrupted reiserfs systems, and it wasn't possible to restore the > >> data (except backups of coures ;)). We're still running reiserfs on > >> our proxy servers (squid), but we have the phenomenon that the > >> machines get slower and slower while squid is running, and if you > >> stop squid and wait some time and start it again it all goes fine > >> again. but the problem isn't squid, it seems to be reiserfs which > >> seems to be not able get all data written to disk in time and slows > >> the computer down. (sure this also depends on the harddisks, but we > >> played around with hdparm and the situation was exactly the same > >> with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be > >> the HDD). For what it's worth: I've had opposite experiences. At one time I had what looked like severe filesystem corruption on my reiserfs disk. But it repaired it without any problems. I've been using it for at least 3 or 4 years now, on all my systems, ranging from laptops to a 0.4 TB raid5 fileserver and I am very happy with both the speed and the reliability. > > I'm confused. How does measuring sequential read/write performance > > map to squid performance? Doesn't squid usually do lots of little > > read/write ops, with lots of seeks too? > > well, the idea was to check if system performance would be influenced > by HDD speed. sure sequential read/write is not really the best test > for this, but i thougth we would see some changes, and since we didn't > the idea was that the HDD isn't the bottleneck. and since the system > behavior is better with ext3 than with reiserfs, the bottleneck may be > the filesystem. I think reiserfs is better than ext3 for lots of small files. Well, actually I think reiserfs is better but then again, I might be biased... ;-) > is it possible to log HDD access (e.g. open, close, read, write, seek, > etc. operations)? Sure. man iostat (package sysstat) (Or give bonnie a try if it is only for benchmarking) Maarten -- Linux: Because rebooting is for adding hardware. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Tue, 2004-04-20 at 08:02, Christoph Moench-Tegeder wrote: > ## Jose Alberto Guzman ([EMAIL PROTECTED]): > > > One recomendation is to always use the latest reiserfs-tools from > > upstream in case of need, as the developers are constantly improving them. > > In case of emergency, I do not want to rely on the latest improvements > (always hoping that all necessary improvements have made their way > into the source...). If you search, you will find reported 'problems' for any of the latest journaling filesystems. All of the solutions for these problems are "use the latest" if you are lucky. If you are unlucky the solution is "will be fixed soon". Bare in mind when googling for problem reports that the oldest and/or most popular will have the most "hits", but this does not make them the "worst"... it often means they are the "best". In the case of Reiser vs JFS vs XFS vs ext3, it depends on what you want. If you want stability and reliability, then maturity is what counts. XFS and JFS have long histories, but not with Linux. ext3 is the newest but is a relatively simple extension to the mature ext2. Reiser was the first journaling filesystem to be included into the Linux kernel, and has paved the way for all the others. Don't let the old history of Reiser bugs put you off; that is a history of bugs found and fixed. The others just haven't got much of a history yet... I think they are all pretty much on par now. For me, inclusion into the standard Linux kernel counts for something; others have already thought hard about what is "ready" to go in, I don't have to duplicate that effort. AFAIK raiser and ext3 are the only ones in so far. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Monday, April 19, 2004, at 03:07 PM, Markus Schabel wrote: well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). I'm confused. How does measuring sequential read/write performance map to squid performance? Doesn't squid usually do lots of little read/write ops, with lots of seeks too? Jeremy
Re: RaiserFS via NFS
## Jose Alberto Guzman ([EMAIL PROTECTED]): > One recomendation is to always use the latest reiserfs-tools from > upstream in case of need, as the developers are constantly improving them. In case of emergency, I do not want to rely on the latest improvements (always hoping that all necessary improvements have made their way into the source...). Regards, Christoph -- Spare Space
Re: RaiserFS via NFS
Jeremy Zawodny wrote: On Monday, April 19, 2004, at 03:07 PM, Markus Schabel wrote: well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). I'm confused. How does measuring sequential read/write performance map to squid performance? Doesn't squid usually do lots of little read/write ops, with lots of seeks too? well, the idea was to check if system performance would be influenced by HDD speed. sure sequential read/write is not really the best test for this, but i thougth we would see some changes, and since we didn't the idea was that the HDD isn't the bottleneck. and since the system behavior is better with ext3 than with reiserfs, the bottleneck may be the filesystem. is it possible to log HDD access (e.g. open, close, read, write, seek, etc. operations)? best regards -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Marcel Hicking wrote: --Sunday, April 18, 2004 10:14:22 +0200 Michelle Konzack <[EMAIL PROTECTED]>: Am I right in that nobody on the list knows whether or not any advantage to running raiserFS is swallowed by NFS? RaiserFs is a realy fast filesystem for very much smal files Well, from bad experience: Reiser seems to have exactly to states: "Working" and "dead". As long as it's working it's very nice. But once you experience problems there's nothing between those two. We had several machines (fortunately no customer systems) just dying with no trace of the source of the problem (RAID5-SCSI- hardware without any faults). They just suddenly died with filesystem error. With all machines we had no luck rebuilding the filesystem. Just out of couriosity I contacted several Linux support company (including SuSE as one of the major supporers of Reiser and the very helpful guys at Bytec) but none could help but most did second our experience with Reiser. But as usual, YMMV. Cheers, Marcel Well, certainly my mileage did vary with reiserfs. The only failiures that have ocurred here, are due to faulty hardware, and they don't happen that often. The last one got a bit nasty, it required a reiserfsck --rebuild-tree, it recovered almost everything (including a fsckd up superblock), and I was most impressed with the results. The rebuild tree process for the 340 G array, took about 2.5 hours. One recomendation is to always use the latest reiserfs-tools from upstream in case of need, as the developers are constantly improving them
Re: RaiserFS via NFS
On Monday, April 19, 2004, at 03:07 PM, Markus Schabel wrote: well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). I'm confused. How does measuring sequential read/write performance map to squid performance? Doesn't squid usually do lots of little read/write ops, with lots of seeks too? Jeremy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
## Jose Alberto Guzman ([EMAIL PROTECTED]): > One recomendation is to always use the latest reiserfs-tools from > upstream in case of need, as the developers are constantly improving them. In case of emergency, I do not want to rely on the latest improvements (always hoping that all necessary improvements have made their way into the source...). Regards, Christoph -- Spare Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Am Mo, den 19.04.2004 schrieb George Georgalis um 19:28: > >As you already wrote - DRBD is a block device, not a filesystem. You > >have to run a filesystem (like reiserfs oder ext3) on top of it, just as > >you would have to with a "normal" block device like a SCSI RAID. > > > >Comparing DRBD to NFS or AFS, well, apples and oranges... > > of course you have to install a fs on a block device. the question was > about network filesystem operability. DRBD to NFS seems like a fair > comparison to me, since they are different. As I understand Andreas, he wants to replace NFS with something different as he has problems with access rights - DRBD is no solution for this problem (as it is no filesystem). You can use DRBD to get a redundant (active/passive) block device using a two-node cluster setup, so you can access your data on the backup node as soon as the primary goes down. You currently CANNOT mount a DRBD block-device simultaneously from more than one node. Active/active is going to be possible in near (?) future, but you'll still need a cluster-filesystem (OpenGFS?) which wont crash as soon as it is mounted more than once... But to access data from various machines you'll have to use NFS, Samba or something like that - on top of $filesystem (reiserFS, ext3, XFS) which itself resides on top of $blockdevice (IDE, SCSI or with an extra layer in between such as DRBD or LVM). > How's your experience with coda, lustre or afs? Haven't used any of them yet as I didn't need any of their features... best regards, Markus -- Markus Oswald <[EMAIL PROTECTED]> \ Unix and Network Administration Graz, AUSTRIA \ High Availability / Cluster Mobile: +43 676 6485415\ System Consulting Fax:+43 316 428896 \ Web Development
Re: RaiserFS via NFS
Marcel Hicking wrote: --Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: I chose ext3 for it's reliablity over ReiserFS. I found ext3 too slow (although rock solid) for large amounts of mail. Since Reiser was no option (too much data loss in the past) we opted for XFS. well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). ext3 is better, but lacks a bit performance with the spool directory since there are many files and directores... we currently switch all proxies to XFS, where this problem doesn't exist (at least at the moment). best regards -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows.
Re: RaiserFS via NFS
Marcel Hicking wrote: --Sunday, April 18, 2004 10:14:22 +0200 Michelle Konzack <[EMAIL PROTECTED]>: Am I right in that nobody on the list knows whether or not any advantage to running raiserFS is swallowed by NFS? RaiserFs is a realy fast filesystem for very much smal files Well, from bad experience: Reiser seems to have exactly to states: "Working" and "dead". As long as it's working it's very nice. But once you experience problems there's nothing between those two. We had several machines (fortunately no customer systems) just dying with no trace of the source of the problem (RAID5-SCSI- hardware without any faults). They just suddenly died with filesystem error. With all machines we had no luck rebuilding the filesystem. Just out of couriosity I contacted several Linux support company (including SuSE as one of the major supporers of Reiser and the very helpful guys at Bytec) but none could help but most did second our experience with Reiser. But as usual, YMMV. Cheers, Marcel Well, certainly my mileage did vary with reiserfs. The only failiures that have ocurred here, are due to faulty hardware, and they don't happen that often. The last one got a bit nasty, it required a reiserfsck --rebuild-tree, it recovered almost everything (including a fsckd up superblock), and I was most impressed with the results. The rebuild tree process for the 340 G array, took about 2.5 hours. One recomendation is to always use the latest reiserfs-tools from upstream in case of need, as the developers are constantly improving them. José -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Am Mo, den 19.04.2004 schrieb George Georgalis um 19:28: > >As you already wrote - DRBD is a block device, not a filesystem. You > >have to run a filesystem (like reiserfs oder ext3) on top of it, just as > >you would have to with a "normal" block device like a SCSI RAID. > > > >Comparing DRBD to NFS or AFS, well, apples and oranges... > > of course you have to install a fs on a block device. the question was > about network filesystem operability. DRBD to NFS seems like a fair > comparison to me, since they are different. As I understand Andreas, he wants to replace NFS with something different as he has problems with access rights - DRBD is no solution for this problem (as it is no filesystem). You can use DRBD to get a redundant (active/passive) block device using a two-node cluster setup, so you can access your data on the backup node as soon as the primary goes down. You currently CANNOT mount a DRBD block-device simultaneously from more than one node. Active/active is going to be possible in near (?) future, but you'll still need a cluster-filesystem (OpenGFS?) which wont crash as soon as it is mounted more than once... But to access data from various machines you'll have to use NFS, Samba or something like that - on top of $filesystem (reiserFS, ext3, XFS) which itself resides on top of $blockdevice (IDE, SCSI or with an extra layer in between such as DRBD or LVM). > How's your experience with coda, lustre or afs? Haven't used any of them yet as I didn't need any of their features... best regards, Markus -- Markus Oswald <[EMAIL PROTECTED]> \ Unix and Network Administration Graz, AUSTRIA \ High Availability / Cluster Mobile: +43 676 6485415\ System Consulting Fax:+43 316 428896 \ Web Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Mon, Apr 19, 2004 at 12:21:53PM +0200, Markus Oswald wrote: >Am Mo, den 19.04.2004 schrieb George Georgalis um 04:40: >> Hi, >> >> You might like DRBD better than AFS, I think AFS is more suited, to >> allow multiple servers to serve /usr/bin, ie static partitions. /var or >> /home partitions need something different. >> >> Coda does sound good. ...just following these, not using them yet, I >> think inter-mezzo is too young still, links: >> >> http://www.drbd.org/ >> Drbd is a block device which is designed to build high availability >> clusters. This is done by mirroring a whole block device via (a >> dedicated) network. You could see it as a network raid-1. > >As you already wrote - DRBD is a block device, not a filesystem. You >have to run a filesystem (like reiserfs oder ext3) on top of it, just as >you would have to with a "normal" block device like a SCSI RAID. > >Comparing DRBD to NFS or AFS, well, apples and oranges... of course you have to install a fs on a block device. the question was about network filesystem operability. DRBD to NFS seems like a fair comparison to me, since they are different. How's your experience with coda, lustre or afs? // George -- George Georgalis, Architect and administrator, Linux services. IXOYE http://www.galis.org/george cell:646-331-2027 mailto:[EMAIL PROTECTED] Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631
Re: RaiserFS via NFS
Marcel Hicking wrote: --Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: I chose ext3 for it's reliablity over ReiserFS. I found ext3 too slow (although rock solid) for large amounts of mail. Since Reiser was no option (too much data loss in the past) we opted for XFS. well, i see the same problem as everybody here: i've had some corrupted reiserfs systems, and it wasn't possible to restore the data (except backups of coures ;)). We're still running reiserfs on our proxy servers (squid), but we have the phenomenon that the machines get slower and slower while squid is running, and if you stop squid and wait some time and start it again it all goes fine again. but the problem isn't squid, it seems to be reiserfs which seems to be not able get all data written to disk in time and slows the computer down. (sure this also depends on the harddisks, but we played around with hdparm and the situation was exactly the same with DMA enabled (140MB/s) and disabled (4MB/s), so it cannot be the HDD). ext3 is better, but lacks a bit performance with the spool directory since there are many files and directores... we currently switch all proxies to XFS, where this problem doesn't exist (at least at the moment). best regards -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Mon, Apr 19, 2004 at 12:21:53PM +0200, Markus Oswald wrote: >Am Mo, den 19.04.2004 schrieb George Georgalis um 04:40: >> Hi, >> >> You might like DRBD better than AFS, I think AFS is more suited, to >> allow multiple servers to serve /usr/bin, ie static partitions. /var or >> /home partitions need something different. >> >> Coda does sound good. ...just following these, not using them yet, I >> think inter-mezzo is too young still, links: >> >> http://www.drbd.org/ >> Drbd is a block device which is designed to build high availability >> clusters. This is done by mirroring a whole block device via (a >> dedicated) network. You could see it as a network raid-1. > >As you already wrote - DRBD is a block device, not a filesystem. You >have to run a filesystem (like reiserfs oder ext3) on top of it, just as >you would have to with a "normal" block device like a SCSI RAID. > >Comparing DRBD to NFS or AFS, well, apples and oranges... of course you have to install a fs on a block device. the question was about network filesystem operability. DRBD to NFS seems like a fair comparison to me, since they are different. How's your experience with coda, lustre or afs? // George -- George Georgalis, Architect and administrator, Linux services. IXOYE http://www.galis.org/george cell:646-331-2027 mailto:[EMAIL PROTECTED] Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Am Mo, den 19.04.2004 schrieb George Georgalis um 04:40: > Hi, > > You might like DRBD better than AFS, I think AFS is more suited, to > allow multiple servers to serve /usr/bin, ie static partitions. /var or > /home partitions need something different. > > Coda does sound good. ...just following these, not using them yet, I > think inter-mezzo is too young still, links: > > http://www.drbd.org/ > Drbd is a block device which is designed to build high availability > clusters. This is done by mirroring a whole block device via (a > dedicated) network. You could see it as a network raid-1. As you already wrote - DRBD is a block device, not a filesystem. You have to run a filesystem (like reiserfs oder ext3) on top of it, just as you would have to with a "normal" block device like a SCSI RAID. Comparing DRBD to NFS or AFS, well, apples and oranges... best regards, Markus -- Markus Oswald <[EMAIL PROTECTED]> \ Unix and Network Administration Graz, AUSTRIA \ High Availability / Cluster Mobile: +43 676 6485415\ System Consulting Fax:+43 316 428896 \ Web Development
Re: RaiserFS via NFS
--Sunday, April 18, 2004 10:14:22 +0200 Michelle Konzack <[EMAIL PROTECTED]>: >> Am I right in that nobody on the list knows whether or not any advantage >> to running raiserFS is swallowed by NFS? > > RaiserFs is a realy fast filesystem for very much smal files Well, from bad experience: Reiser seems to have exactly to states: "Working" and "dead". As long as it's working it's very nice. But once you experience problems there's nothing between those two. We had several machines (fortunately no customer systems) just dying with no trace of the source of the problem (RAID5-SCSI- hardware without any faults). They just suddenly died with filesystem error. With all machines we had no luck rebuilding the filesystem. Just out of couriosity I contacted several Linux support company (including SuSE as one of the major supporers of Reiser and the very helpful guys at Bytec) but none could help but most did second our experience with Reiser. But as usual, YMMV. Cheers, Marcel
Re: RaiserFS via NFS
Am Mo, den 19.04.2004 schrieb George Georgalis um 04:40: > Hi, > > You might like DRBD better than AFS, I think AFS is more suited, to > allow multiple servers to serve /usr/bin, ie static partitions. /var or > /home partitions need something different. > > Coda does sound good. ...just following these, not using them yet, I > think inter-mezzo is too young still, links: > > http://www.drbd.org/ > Drbd is a block device which is designed to build high availability > clusters. This is done by mirroring a whole block device via (a > dedicated) network. You could see it as a network raid-1. As you already wrote - DRBD is a block device, not a filesystem. You have to run a filesystem (like reiserfs oder ext3) on top of it, just as you would have to with a "normal" block device like a SCSI RAID. Comparing DRBD to NFS or AFS, well, apples and oranges... best regards, Markus -- Markus Oswald <[EMAIL PROTECTED]> \ Unix and Network Administration Graz, AUSTRIA \ High Availability / Cluster Mobile: +43 676 6485415\ System Consulting Fax:+43 316 428896 \ Web Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
--Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: > I chose ext3 for it's reliablity over ReiserFS. I found ext3 too slow (although rock solid) for large amounts of mail. Since Reiser was no option (too much data loss in the past) we opted for XFS. Cheers, Marcel
Re: RaiserFS via NFS
--Sunday, April 18, 2004 01:43:43 +0200 Andreas John <[EMAIL PROTECTED]>: > Just to be curious: I'm thinking for some time about using andrew fs, i.e. > coda instead of NFS. Good luck. My experiments with CODA were quite disappointing. Already the first run with bonnie++ for performance checking corrupted the filesystem. But possibly I gave up too fast ;-) AFS, or probably OpenAFS is quite complex, InterMezzo still looks alpha and not suitable for production. DRDB on the other hand seems more mature and as a very simple approach. Let us know to what results you came. Cheers, Marcel
Re: RaiserFS via NFS
--Sunday, April 18, 2004 10:14:22 +0200 Michelle Konzack <[EMAIL PROTECTED]>: >> Am I right in that nobody on the list knows whether or not any advantage >> to running raiserFS is swallowed by NFS? > > RaiserFs is a realy fast filesystem for very much smal files Well, from bad experience: Reiser seems to have exactly to states: "Working" and "dead". As long as it's working it's very nice. But once you experience problems there's nothing between those two. We had several machines (fortunately no customer systems) just dying with no trace of the source of the problem (RAID5-SCSI- hardware without any faults). They just suddenly died with filesystem error. With all machines we had no luck rebuilding the filesystem. Just out of couriosity I contacted several Linux support company (including SuSE as one of the major supporers of Reiser and the very helpful guys at Bytec) but none could help but most did second our experience with Reiser. But as usual, YMMV. Cheers, Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
--Saturday, April 17, 2004 11:38:56 -0700 Chad Cranston <[EMAIL PROTECTED]>: > I chose ext3 for it's reliablity over ReiserFS. I found ext3 too slow (although rock solid) for large amounts of mail. Since Reiser was no option (too much data loss in the past) we opted for XFS. Cheers, Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
--Sunday, April 18, 2004 01:43:43 +0200 Andreas John <[EMAIL PROTECTED]>: > Just to be curious: I'm thinking for some time about using andrew fs, i.e. > coda instead of NFS. Good luck. My experiments with CODA were quite disappointing. Already the first run with bonnie++ for performance checking corrupted the filesystem. But possibly I gave up too fast ;-) AFS, or probably OpenAFS is quite complex, InterMezzo still looks alpha and not suitable for production. DRDB on the other hand seems more mature and as a very simple approach. Let us know to what results you came. Cheers, Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Hi, You might like DRBD better than AFS, I think AFS is more suited, to allow multiple servers to serve /usr/bin, ie static partitions. /var or /home partitions need something different. Coda does sound good. ...just following these, not using them yet, I think inter-mezzo is too young still, links: http://www.drbd.org/ Drbd is a block device which is designed to build high availability clusters. This is done by mirroring a whole block device via (a dedicated) network. You could see it as a network raid-1. http://www.lustre.org/ The 1.0 release of Lustre is now available, and is suitable for clusters with thousands of nodes and hundreds of terabytes of storage. http://opengfs.sourceforge.net/docs.php The Open Global File System (OpenGFS, or OGFS) is a journaled filesystem that supports simultaneous sharing of a common storage device by multiple computer nodes. http://www.coda.cs.cmu.edu/ Coda is a distributed filesystem with its origin in AFS2. http://www.inter-mezzo.org/docs.html InterMezzo will be suitable for replication of servers, mobile computing, managing system software on large clusters, and for maintenance of high availability clusters. // George On Sun, Apr 18, 2004 at 01:43:43AM +0200, Andreas John wrote: >Hello! > >Just to be curious: I'm thinking for some time about using andrew fs, >i.e. coda instead of NFS. I don't like NFS, due to complications with >access rights (Yes, I use ugidd). But it sounds like the locking problem >ist also not solved with coda, right? > >rgds, >j. > > >Andrew Miehs wrote: >>I suggest you all read >> >>http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html >> >>Especially the sentence >>'Thus, Postfix on NFS is slightly less reliable than Postfix on a local >>disk.' >> >>Either something is reliable or not. there is no such thing as slightly >>less reliable. >> >>Especially when it comes to mail. With Maildir you will have less >>problems than with mbox, >>but you still do NOT have atomic transactions, and as such you will at >>some stage >>statistically have a problem. >> > > >-- >Andreas John >net-lab GmbH >Luisenstrasse 30b >63067 Offenbach >Tel: +49 69 85700331 > >http://www.net-lab.net > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact >[EMAIL PROTECTED] > -- George Georgalis, Architect and administrator, Linux services. IXOYE http://www.galis.org/george cell:646-331-2027 mailto:[EMAIL PROTECTED] Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631
Re: RaiserFS via NFS
Hi, You might like DRBD better than AFS, I think AFS is more suited, to allow multiple servers to serve /usr/bin, ie static partitions. /var or /home partitions need something different. Coda does sound good. ...just following these, not using them yet, I think inter-mezzo is too young still, links: http://www.drbd.org/ Drbd is a block device which is designed to build high availability clusters. This is done by mirroring a whole block device via (a dedicated) network. You could see it as a network raid-1. http://www.lustre.org/ The 1.0 release of Lustre is now available, and is suitable for clusters with thousands of nodes and hundreds of terabytes of storage. http://opengfs.sourceforge.net/docs.php The Open Global File System (OpenGFS, or OGFS) is a journaled filesystem that supports simultaneous sharing of a common storage device by multiple computer nodes. http://www.coda.cs.cmu.edu/ Coda is a distributed filesystem with its origin in AFS2. http://www.inter-mezzo.org/docs.html InterMezzo will be suitable for replication of servers, mobile computing, managing system software on large clusters, and for maintenance of high availability clusters. // George On Sun, Apr 18, 2004 at 01:43:43AM +0200, Andreas John wrote: >Hello! > >Just to be curious: I'm thinking for some time about using andrew fs, >i.e. coda instead of NFS. I don't like NFS, due to complications with >access rights (Yes, I use ugidd). But it sounds like the locking problem >ist also not solved with coda, right? > >rgds, >j. > > >Andrew Miehs wrote: >>I suggest you all read >> >>http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html >> >>Especially the sentence >>'Thus, Postfix on NFS is slightly less reliable than Postfix on a local >>disk.' >> >>Either something is reliable or not. there is no such thing as slightly >>less reliable. >> >>Especially when it comes to mail. With Maildir you will have less >>problems than with mbox, >>but you still do NOT have atomic transactions, and as such you will at >>some stage >>statistically have a problem. >> > > >-- >Andreas John >net-lab GmbH >Luisenstrasse 30b >63067 Offenbach >Tel: +49 69 85700331 > >http://www.net-lab.net > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact >[EMAIL PROTECTED] > -- George Georgalis, Architect and administrator, Linux services. IXOYE http://www.galis.org/george cell:646-331-2027 mailto:[EMAIL PROTECTED] Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Sunday 18 April 2004 01:16, Andrew Miehs wrote: > 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local > disk.' > > Either something is reliable or not. there is no such thing as slightly > less reliable. I do not agree with that general sentence at all ! That is akin to saying "something is secure or it is not". No, nothing ever is 100% secure, and neither is "100% reliable" an attainable goal. But going back to the ISP. They have so much mail that they have multiple frontends and backends. Many of them. Are you suggesting that they should revert to a one-single-box mail hub to _improve_reliability_ ? I think not. Maarten
Re: RaiserFS via NFS
On Sunday 18 April 2004 01:16, Andrew Miehs wrote: > 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local > disk.' > > Either something is reliable or not. there is no such thing as slightly > less reliable. I do not agree with that general sentence at all ! That is akin to saying "something is secure or it is not". No, nothing ever is 100% secure, and neither is "100% reliable" an attainable goal. But going back to the ISP. They have so much mail that they have multiple frontends and backends. Many of them. Are you suggesting that they should revert to a one-single-box mail hub to _improve_reliability_ ? I think not. Maarten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Hello All! Please please note that the filesystem's name in question is not r_a_iserFS, but r_e_iserFS. It was given that name by it's inventor Hans Reiser. ReiserFS as I stated before does not "raise" anything (except maybe the usable disk space when working with many large files). Concerning the NFS question: There are several services out that do their error-correction by themselves and don't rely on tcp's error correction. E.G. error correction for an audio stream maybe to drop a paket without doing harm to the listening quality. I do not know if NFS has an internal error correction but I heavily assume it. Every thing else would make absolutely no sense. NFS will have request pakets again if the sequence numbers go out of sync. Maybe it can do that more efficient than TCP by reconstruction of lost pakets/data via checksum (science-fiction ?) Using TCP has advantages if you use IntServ instead of DiffServ QoS or do firewalling with NFS. Maybe there was an "bad LAN" Michelle's case and NFS had to re-request mayn pakets? Best Regards, J. Michelle Konzack wrote: Am 2004-04-17 23:29:56, schrieb Dan MacNeil: On Sat, 17 Apr 2004, Michelle Konzack wrote in part: But use a self-compiled Linux with nfs and nfsd compiled WITH "TCP" and "v3" support. if you mount your server add "nfsvers=3,tcp" to it otherwise it will use UDP which is realy not good. Why? from my (maybe wrong?) reading of the docs, the advantage of TCP is that it is hard to spoof given that it is connection oriented. But with UDP you no Error-Correction ! The quality of the connection increase with TCP. (own experience specialy for large files) I plan to run NFS on a completely internal network and configure iptables to drop packets from outside the network. The NFS server will not be connected to the outside world and the application servers will have 2 My NFS works like yours too. NICs one for the internal Gb/sec 10.0.0.* network and one for the outside world. Am I right in that nobody on the list knows whether or not any advantage to running raiserFS is swallowed by NFS? RaiserFs is a realy fast filesystem for very much smal files Greetings Michelle -- Andreas John net-lab GmbH Luisenstrasse 30b 63067 Offenbach Tel: +49 69 85700331 http://www.net-lab.net
Re: RaiserFS via NFS
Am So, den 18.04.2004 schrieb Andrew Miehs um 01:16: > I suggest you all read > > http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html > > Especially the sentence > 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local > disk.' > > Either something is reliable or not. there is no such thing as slightly > less reliable. I suggest you read it first... Quote from NFS_README.html: --- # In order to have mailbox locking over NFS you have to configure # everything to use fcntl() locks for mailbox access (or switch to # maildir style, which needs no application-level lock controls). So if you use maildir (which you probably will with a setup like this) you won't have any problems with NFS at all. And yes, we run setups like this - with some hundred thousand mails per day - and never had a problem... best regards, Markus -- Markus Oswald <[EMAIL PROTECTED]> \ Unix and Network Administration Graz, AUSTRIA \ High Availability / Cluster Mobile: +43 676 6485415\ System Consulting Fax:+43 316 428896 \ Web Development
Re: RaiserFS via NFS
Hello All! Please please note that the filesystem's name in question is not r_a_iserFS, but r_e_iserFS. It was given that name by it's inventor Hans Reiser. ReiserFS as I stated before does not "raise" anything (except maybe the usable disk space when working with many large files). Concerning the NFS question: There are several services out that do their error-correction by themselves and don't rely on tcp's error correction. E.G. error correction for an audio stream maybe to drop a paket without doing harm to the listening quality. I do not know if NFS has an internal error correction but I heavily assume it. Every thing else would make absolutely no sense. NFS will have request pakets again if the sequence numbers go out of sync. Maybe it can do that more efficient than TCP by reconstruction of lost pakets/data via checksum (science-fiction ?) Using TCP has advantages if you use IntServ instead of DiffServ QoS or do firewalling with NFS. Maybe there was an "bad LAN" Michelle's case and NFS had to re-request mayn pakets? Best Regards, J. Michelle Konzack wrote: Am 2004-04-17 23:29:56, schrieb Dan MacNeil: On Sat, 17 Apr 2004, Michelle Konzack wrote in part: But use a self-compiled Linux with nfs and nfsd compiled WITH "TCP" and "v3" support. if you mount your server add "nfsvers=3,tcp" to it otherwise it will use UDP which is realy not good. Why? from my (maybe wrong?) reading of the docs, the advantage of TCP is that it is hard to spoof given that it is connection oriented. But with UDP you no Error-Correction ! The quality of the connection increase with TCP. (own experience specialy for large files) I plan to run NFS on a completely internal network and configure iptables to drop packets from outside the network. The NFS server will not be connected to the outside world and the application servers will have 2 My NFS works like yours too. NICs one for the internal Gb/sec 10.0.0.* network and one for the outside world. Am I right in that nobody on the list knows whether or not any advantage to running raiserFS is swallowed by NFS? RaiserFs is a realy fast filesystem for very much smal files Greetings Michelle -- Andreas John net-lab GmbH Luisenstrasse 30b 63067 Offenbach Tel: +49 69 85700331 http://www.net-lab.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Am So, den 18.04.2004 schrieb Andrew Miehs um 01:16: > I suggest you all read > > http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html > > Especially the sentence > 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local > disk.' > > Either something is reliable or not. there is no such thing as slightly > less reliable. I suggest you read it first... Quote from NFS_README.html: --- # In order to have mailbox locking over NFS you have to configure # everything to use fcntl() locks for mailbox access (or switch to # maildir style, which needs no application-level lock controls). So if you use maildir (which you probably will with a setup like this) you won't have any problems with NFS at all. And yes, we run setups like this - with some hundred thousand mails per day - and never had a problem... best regards, Markus -- Markus Oswald <[EMAIL PROTECTED]> \ Unix and Network Administration Graz, AUSTRIA \ High Availability / Cluster Mobile: +43 676 6485415\ System Consulting Fax:+43 316 428896 \ Web Development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Am 2004-04-17 23:29:56, schrieb Dan MacNeil: > >On Sat, 17 Apr 2004, Michelle Konzack wrote in part: > >>But use a self-compiled Linux with nfs and nfsd compiled WITH >>"TCP" and "v3" support. > >>if you mount your server add "nfsvers=3,tcp" to it otherwise it >>will use UDP which is realy not good. > >Why? from my (maybe wrong?) reading of the docs, the advantage of TCP is >that it is hard to spoof given that it is connection oriented. But with UDP you no Error-Correction ! The quality of the connection increase with TCP. (own experience specialy for large files) >I plan to run NFS on a completely internal network and configure iptables >to drop packets from outside the network. The NFS server will not be >connected to the outside world and the application servers will have 2 My NFS works like yours too. >NICs one for the internal Gb/sec 10.0.0.* network and one for the outside >world. >Am I right in that nobody on the list knows whether or not any advantage >to running raiserFS is swallowed by NFS? RaiserFs is a realy fast filesystem for very much smal files Greetings Michelle -- Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/
Re: RaiserFS via NFS
Am 2004-04-17 23:29:56, schrieb Dan MacNeil: > >On Sat, 17 Apr 2004, Michelle Konzack wrote in part: > >>But use a self-compiled Linux with nfs and nfsd compiled WITH >>"TCP" and "v3" support. > >>if you mount your server add "nfsvers=3,tcp" to it otherwise it >>will use UDP which is realy not good. > >Why? from my (maybe wrong?) reading of the docs, the advantage of TCP is >that it is hard to spoof given that it is connection oriented. But with UDP you no Error-Correction ! The quality of the connection increase with TCP. (own experience specialy for large files) >I plan to run NFS on a completely internal network and configure iptables >to drop packets from outside the network. The NFS server will not be >connected to the outside world and the application servers will have 2 My NFS works like yours too. >NICs one for the internal Gb/sec 10.0.0.* network and one for the outside >world. >Am I right in that nobody on the list knows whether or not any advantage >to running raiserFS is swallowed by NFS? RaiserFs is a realy fast filesystem for very much smal files Greetings Michelle -- Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Sat, 17 Apr 2004, Michelle Konzack wrote in part: >But use a self-compiled Linux with nfs and nfsd compiled WITH >"TCP" and "v3" support. >if you mount your server add "nfsvers=3,tcp" to it otherwise it >will use UDP which is realy not good. Why? from my (maybe wrong?) reading of the docs, the advantage of TCP is that it is hard to spoof given that it is connection oriented. I plan to run NFS on a completely internal network and configure iptables to drop packets from outside the network. The NFS server will not be connected to the outside world and the application servers will have 2 NICs one for the internal Gb/sec 10.0.0.* network and one for the outside world. Andrew Miehs writes in part: > I suggest you all read > http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html > Especially when it comes to mail. With Maildir you will have less > problems than with mbox, but you still do NOT have atomic transactions, > and as such you will at some stage statistically have a problem. Porcupine says in part: [empathizes added] > switch to maildir style, which needs *no* application-level lock > controls). Other people say: >[DONT USE NFS FOR MAIL OR YOUR PRIVATE PARTS WILL > BE EATEN BY GOLD FISH] See: the spec for maildir http://www.qmail.org/man/man5/maildir.html I can't say I've ever seen a convincing argument against maildir's safety... Am I right in that nobody on the list knows whether or not any advantage to running raiserFS is swallowed by NFS?
Re: RaiserFS via NFS
On Sat, 17 Apr 2004, Michelle Konzack wrote in part: >But use a self-compiled Linux with nfs and nfsd compiled WITH >"TCP" and "v3" support. >if you mount your server add "nfsvers=3,tcp" to it otherwise it >will use UDP which is realy not good. Why? from my (maybe wrong?) reading of the docs, the advantage of TCP is that it is hard to spoof given that it is connection oriented. I plan to run NFS on a completely internal network and configure iptables to drop packets from outside the network. The NFS server will not be connected to the outside world and the application servers will have 2 NICs one for the internal Gb/sec 10.0.0.* network and one for the outside world. Andrew Miehs writes in part: > I suggest you all read > http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html > Especially when it comes to mail. With Maildir you will have less > problems than with mbox, but you still do NOT have atomic transactions, > and as such you will at some stage statistically have a problem. Porcupine says in part: [empathizes added] > switch to maildir style, which needs *no* application-level lock > controls). Other people say: >[DONT USE NFS FOR MAIL OR YOUR PRIVATE PARTS WILL > BE EATEN BY GOLD FISH] See: the spec for maildir http://www.qmail.org/man/man5/maildir.html I can't say I've ever seen a convincing argument against maildir's safety... Am I right in that nobody on the list knows whether or not any advantage to running raiserFS is swallowed by NFS? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Hello! Just to be curious: I'm thinking for some time about using andrew fs, i.e. coda instead of NFS. I don't like NFS, due to complications with access rights (Yes, I use ugidd). But it sounds like the locking problem ist also not solved with coda, right? rgds, j. Andrew Miehs wrote: I suggest you all read http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html Especially the sentence 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local disk.' Either something is reliable or not. there is no such thing as slightly less reliable. Especially when it comes to mail. With Maildir you will have less problems than with mbox, but you still do NOT have atomic transactions, and as such you will at some stage statistically have a problem. -- Andreas John net-lab GmbH Luisenstrasse 30b 63067 Offenbach Tel: +49 69 85700331 http://www.net-lab.net
Re: RaiserFS via NFS
I suggest you all read http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html Especially the sentence 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local disk.' Either something is reliable or not. there is no such thing as slightly less reliable. Especially when it comes to mail. With Maildir you will have less problems than with mbox, but you still do NOT have atomic transactions, and as such you will at some stage statistically have a problem. Andrew On 17.04.2004, at 21:55, Maarten wrote: On Saturday 17 April 2004 20:22, Michael Loftis wrote: You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* to deal with. It WILL corrupt your users mail, it WILL lose mail. It will NOT work. Yeah Well My ISP, as have others undoubtedly, has their mailspools on a bigass NetApp, mounted over NFS. They must be out of their friggin' minds!
Re: RaiserFS via NFS
Hello! Just to be curious: I'm thinking for some time about using andrew fs, i.e. coda instead of NFS. I don't like NFS, due to complications with access rights (Yes, I use ugidd). But it sounds like the locking problem ist also not solved with coda, right? rgds, j. Andrew Miehs wrote: I suggest you all read http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html Especially the sentence 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local disk.' Either something is reliable or not. there is no such thing as slightly less reliable. Especially when it comes to mail. With Maildir you will have less problems than with mbox, but you still do NOT have atomic transactions, and as such you will at some stage statistically have a problem. -- Andreas John net-lab GmbH Luisenstrasse 30b 63067 Offenbach Tel: +49 69 85700331 http://www.net-lab.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
I suggest you all read http://www.porcupine.org/postfix-mirror/newdoc/NFS_README.html Especially the sentence 'Thus, Postfix on NFS is slightly less reliable than Postfix on a local disk.' Either something is reliable or not. there is no such thing as slightly less reliable. Especially when it comes to mail. With Maildir you will have less problems than with mbox, but you still do NOT have atomic transactions, and as such you will at some stage statistically have a problem. Andrew On 17.04.2004, at 21:55, Maarten wrote: On Saturday 17 April 2004 20:22, Michael Loftis wrote: You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* to deal with. It WILL corrupt your users mail, it WILL lose mail. It will NOT work. Yeah Well My ISP, as have others undoubtedly, has their mailspools on a bigass NetApp, mounted over NFS. They must be out of their friggin' minds! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Saturday 17 April 2004 20:22, Michael Loftis wrote: > You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* > to deal with. It WILL corrupt your users mail, it WILL lose mail. It will > NOT work. Yeah Well My ISP, as have others undoubtedly, has their mailspools on a bigass NetApp, mounted over NFS. They must be out of their friggin' minds! P.S.: Please reply at least three or four times to my message if you want me to receive them; for some obscure reason we lose mail on a daily basis... ;-)) Maarten -- Linux: Because rebooting is for adding hardware.
Re: RaiserFS via NFS
Hello Michael, Am 2004-04-17 12:22:57, schrieb Michael Loftis: >You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* >to deal with. It WILL corrupt your users mail, it WILL lose mail. It will >NOT work. Experience with mailbox ;-) Right, if I open linux-kernel as mailbox then I have the Hell with a 37-40 MByte big file which will locked... and fetchmail can not add new messages or you have deleted one and your mailbox ned to be updated... But th OP was talking about Maildir !!! You have on file for each Message... No locking and other troubles... I have on my FileServer (nfs-kernel-server, netatalk, samba) more then 4,7 million Messages und use it day for fay. never lost one Message. The only thing I have done was to filter this in ~/.procmailrc :0 fh | formail -f -I Received: -I Envelope-to: -I Delivered-To: -I Return-path: to save Diskspace (blocksize 1024 Bytes) >Michael Loftis Greetings Michelle -- Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/
Re: RaiserFS via NFS
On Sat, Apr 17, 2004 at 12:22:57PM -0600, Michael Loftis wrote: >You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* >to deal with. It WILL corrupt your users mail, it WILL lose mail. It will >NOT work. > DO you KNOW what maildir IS? // George >--On Saturday, April 17, 2004 12:51 -0400 Dan MacNeil ><[EMAIL PROTECTED]> wrote: > >> >>I've just converted from mbox to maildir >> >>Right now there are some users with 500 files in a directory, I expect >>this go grow. >> >>I expect this figure to grow. RaiserFS is looking good. >> >>The benefits of running a central storage server and a bunch of separate >>web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not >>much more than NFS all connected with a cheap Gigbit switch are also >>appealing to me. >> >>Is there any benefit to RaiserFS if I am accessing it via NFS ? >> -- George Georgalis, Architect and administrator, Linux services. IXOYE http://www.galis.org/george cell:646-331-2027 mailto:[EMAIL PROTECTED] Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631
Re: RaiserFS via NFS
I second that motion ! Just make sure that you are dumping only deliverd mail to an NFS mount. Keep the spools local. NFS + file locking don't mix. I chose ext3 for it's reliablity over ReiserFS. But it is GREAT having a small farm of M$ filtering servers (spam / virii) on the front end. -Chad - Original Message - From: "Michael Loftis" <[EMAIL PROTECTED]> To: "Dan MacNeil" <[EMAIL PROTECTED]>; Sent: Saturday, April 17, 2004 11:22 AM Subject: Re: RaiserFS via NFS > You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* > to deal with. It WILL corrupt your users mail, it WILL lose mail. It will > NOT work. > > --On Saturday, April 17, 2004 12:51 -0400 Dan MacNeil > <[EMAIL PROTECTED]> wrote: > > > > > I've just converted from mbox to maildir > > > > Right now there are some users with 500 files in a directory, I expect > > this go grow. > > > > I expect this figure to grow. RaiserFS is looking good. > > > > The benefits of running a central storage server and a bunch of separate > > web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not > > much more than NFS all connected with a cheap Gigbit switch are also > > appealing to me. > > > > Is there any benefit to RaiserFS if I am accessing it via NFS ? > > > > > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > > > > > > > > > -- > Michael Loftis > Modwest Sr. Systems Administrator > Powerful, Affordable Web Hosting > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: RaiserFS via NFS
You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* to deal with. It WILL corrupt your users mail, it WILL lose mail. It will NOT work. --On Saturday, April 17, 2004 12:51 -0400 Dan MacNeil <[EMAIL PROTECTED]> wrote: I've just converted from mbox to maildir Right now there are some users with 500 files in a directory, I expect this go grow. I expect this figure to grow. RaiserFS is looking good. The benefits of running a central storage server and a bunch of separate web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not much more than NFS all connected with a cheap Gigbit switch are also appealing to me. Is there any benefit to RaiserFS if I am accessing it via NFS ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Michael Loftis Modwest Sr. Systems Administrator Powerful, Affordable Web Hosting
Re: RaiserFS via NFS
On Saturday 17 April 2004 20:22, Michael Loftis wrote: > You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* > to deal with. It WILL corrupt your users mail, it WILL lose mail. It will > NOT work. Yeah Well My ISP, as have others undoubtedly, has their mailspools on a bigass NetApp, mounted over NFS. They must be out of their friggin' minds! P.S.: Please reply at least three or four times to my message if you want me to receive them; for some obscure reason we lose mail on a daily basis... ;-)) Maarten -- Linux: Because rebooting is for adding hardware. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Am 2004-04-17 12:51:32, schrieb Dan MacNeil: > >I've just converted from mbox to maildir > >Right now there are some users with 500 files in a directory, I expect >this go grow. > >I expect this figure to grow. RaiserFS is looking good. > >The benefits of running a central storage server and a bunch of seperate >web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not >much more than NFS all connected with a cheap Gigbit switch are also >appealing to me. > >Is there any benefit to RaiserFS if I am accessing it via NFS ? For NFS not. But RaiserFS is realy faster then ext2. I am using ext3 and have in some Mailboxes (e.g. linux-kernel) 7-8000 Messages without any problems using a "3Com Superstack II 3900 Switch" where my NFS-Server is on a GBit Port. But use a self-compiled Linux with nfs and nfsd compiled WITH "TCP" and "v3" support. if you mount your server add "nfsvers=3,tcp" to it otherwise it will use UDP which is realy not good. Greetings Michelle -- Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/
Re: RaiserFS via NFS
Dan MacNeil wrote: I've just converted from mbox to maildir Right now there are some users with 500 files in a directory, I expect this go grow. Even if it grows Factor 2 it's nothing you need to be afraid of with extX. Sometimes we have so many files in directory that "ls" overflows :-) I expect this figure to grow. RaiserFS is looking good. It's worth a look anyway. For us it has proven stable, even with linux softraid (after kernel 2.4.9 (?) which caused our filesystem to die) Actually ReiserFS lowers (and not "raises" ;)) the disk space wasted due to smarter allocation of blocks. The benefits of running a central storage server and a bunch of seperate web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not much more than NFS all connected with a cheap Gigbit switch are also appealing to me. There have been a couple of questions concerning "quota", but AFAIR the reiserFS quota patches are even in vanilla kernels now. Is there any benefit to RaiserFS if I am accessing it via NFS ? Yes, the benefit is that you may read the data via network!!! *g* Not the answer you expected? If your CPU is not a slow old mule, reiserFS should give you more performance when accessing small files. You may ask google about benchmarks, there are some pages out. Compare it also so XFS and JFS. If it comes to question "what is best" the answer is: Depends on you needs! E.G. reiserFS has do "dump" utility, XFS offers ACLs by default, alloffer journals, reiser4 ships with a "database structure", for extX there are most recue utils out, for laptops a journaling FS can cause power consumption, so ext2 may be cool for them. Large file access may be better with FS A, databases may like FS B more etc Rgds, J. -- Andreas John net-lab GmbH Luisenstrasse 30b 63067 Offenbach Tel: +49 69 85700331 http://www.net-lab.net
Re: RaiserFS via NFS
Hello Michael, Am 2004-04-17 12:22:57, schrieb Michael Loftis: >You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* >to deal with. It WILL corrupt your users mail, it WILL lose mail. It will >NOT work. Experience with mailbox ;-) Right, if I open linux-kernel as mailbox then I have the Hell with a 37-40 MByte big file which will locked... and fetchmail can not add new messages or you have deleted one and your mailbox ned to be updated... But th OP was talking about Maildir !!! You have on file for each Message... No locking and other troubles... I have on my FileServer (nfs-kernel-server, netatalk, samba) more then 4,7 million Messages und use it day for fay. never lost one Message. The only thing I have done was to filter this in ~/.procmailrc :0 fh | formail -f -I Received: -I Envelope-to: -I Delivered-To: -I Return-path: to save Diskspace (blocksize 1024 Bytes) >Michael Loftis Greetings Michelle -- Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
On Sat, Apr 17, 2004 at 12:22:57PM -0600, Michael Loftis wrote: >You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* >to deal with. It WILL corrupt your users mail, it WILL lose mail. It will >NOT work. > DO you KNOW what maildir IS? // George >--On Saturday, April 17, 2004 12:51 -0400 Dan MacNeil ><[EMAIL PROTECTED]> wrote: > >> >>I've just converted from mbox to maildir >> >>Right now there are some users with 500 files in a directory, I expect >>this go grow. >> >>I expect this figure to grow. RaiserFS is looking good. >> >>The benefits of running a central storage server and a bunch of separate >>web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not >>much more than NFS all connected with a cheap Gigbit switch are also >>appealing to me. >> >>Is there any benefit to RaiserFS if I am accessing it via NFS ? >> -- George Georgalis, Architect and administrator, Linux services. IXOYE http://www.galis.org/george cell:646-331-2027 mailto:[EMAIL PROTECTED] Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
I second that motion ! Just make sure that you are dumping only deliverd mail to an NFS mount. Keep the spools local. NFS + file locking don't mix. I chose ext3 for it's reliablity over ReiserFS. But it is GREAT having a small farm of M$ filtering servers (spam / virii) on the front end. -Chad - Original Message - From: "Michael Loftis" <[EMAIL PROTECTED]> To: "Dan MacNeil" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, April 17, 2004 11:22 AM Subject: Re: RaiserFS via NFS > You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* > to deal with. It WILL corrupt your users mail, it WILL lose mail. It will > NOT work. > > --On Saturday, April 17, 2004 12:51 -0400 Dan MacNeil > <[EMAIL PROTECTED]> wrote: > > > > > I've just converted from mbox to maildir > > > > Right now there are some users with 500 files in a directory, I expect > > this go grow. > > > > I expect this figure to grow. RaiserFS is looking good. > > > > The benefits of running a central storage server and a bunch of separate > > web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not > > much more than NFS all connected with a cheap Gigbit switch are also > > appealing to me. > > > > Is there any benefit to RaiserFS if I am accessing it via NFS ? > > > > > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > > > > > > > > > -- > Michael Loftis > Modwest Sr. Systems Administrator > Powerful, Affordable Web Hosting > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
You can not, and DO NOT put your mail spool on NFS. You *WILL* have *HELL* to deal with. It WILL corrupt your users mail, it WILL lose mail. It will NOT work. --On Saturday, April 17, 2004 12:51 -0400 Dan MacNeil <[EMAIL PROTECTED]> wrote: I've just converted from mbox to maildir Right now there are some users with 500 files in a directory, I expect this go grow. I expect this figure to grow. RaiserFS is looking good. The benefits of running a central storage server and a bunch of separate web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not much more than NFS all connected with a cheap Gigbit switch are also appealing to me. Is there any benefit to RaiserFS if I am accessing it via NFS ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Michael Loftis Modwest Sr. Systems Administrator Powerful, Affordable Web Hosting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Am 2004-04-17 12:51:32, schrieb Dan MacNeil: > >I've just converted from mbox to maildir > >Right now there are some users with 500 files in a directory, I expect >this go grow. > >I expect this figure to grow. RaiserFS is looking good. > >The benefits of running a central storage server and a bunch of seperate >web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not >much more than NFS all connected with a cheap Gigbit switch are also >appealing to me. > >Is there any benefit to RaiserFS if I am accessing it via NFS ? For NFS not. But RaiserFS is realy faster then ext2. I am using ext3 and have in some Mailboxes (e.g. linux-kernel) 7-8000 Messages without any problems using a "3Com Superstack II 3900 Switch" where my NFS-Server is on a GBit Port. But use a self-compiled Linux with nfs and nfsd compiled WITH "TCP" and "v3" support. if you mount your server add "nfsvers=3,tcp" to it otherwise it will use UDP which is realy not good. Greetings Michelle -- Registered Linux-User #280138 with the Linux Counter, http://counter.li.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RaiserFS via NFS
Dan MacNeil wrote: I've just converted from mbox to maildir Right now there are some users with 500 files in a directory, I expect this go grow. Even if it grows Factor 2 it's nothing you need to be afraid of with extX. Sometimes we have so many files in directory that "ls" overflows :-) I expect this figure to grow. RaiserFS is looking good. It's worth a look anyway. For us it has proven stable, even with linux softraid (after kernel 2.4.9 (?) which caused our filesystem to die) Actually ReiserFS lowers (and not "raises" ;)) the disk space wasted due to smarter allocation of blocks. The benefits of running a central storage server and a bunch of seperate web/smtp/pop3/spamfiltering/ftp/ servers, one storage server running not much more than NFS all connected with a cheap Gigbit switch are also appealing to me. There have been a couple of questions concerning "quota", but AFAIR the reiserFS quota patches are even in vanilla kernels now. Is there any benefit to RaiserFS if I am accessing it via NFS ? Yes, the benefit is that you may read the data via network!!! *g* Not the answer you expected? If your CPU is not a slow old mule, reiserFS should give you more performance when accessing small files. You may ask google about benchmarks, there are some pages out. Compare it also so XFS and JFS. If it comes to question "what is best" the answer is: Depends on you needs! E.G. reiserFS has do "dump" utility, XFS offers ACLs by default, alloffer journals, reiser4 ships with a "database structure", for extX there are most recue utils out, for laptops a journaling FS can cause power consumption, so ext2 may be cool for them. Large file access may be better with FS A, databases may like FS B more etc Rgds, J. -- Andreas John net-lab GmbH Luisenstrasse 30b 63067 Offenbach Tel: +49 69 85700331 http://www.net-lab.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
