Re: [reiserfs-list] File size limit exceeded
Hi Jeff Wilde wrote: I ran into a problem upgrading to the kernel 2.4.9 in that I got file size limit exceeded on the following: -rw-rw1 root root 53812 Aug 30 11:23 radacct.MYD -rw-rw1 root root 396383232 Aug 30 11:23 radacct.MYI It resulted in a core dump of my server (radius). It seems to work just find under 2.2.18. I can't seem to locate where the size is displayed in the source code, but to me it looks like these sizes are just fine according to the faq. Any help would be appreciated in locating the variable I need to set =). Sorry, could you please provide more information? Do you get a signal SIGXFSZ when appendign to those files? How much are you trying to write? Note that you can not write more than 2gb into reiserfs files created under 2.2. Thanks, vs Thanx in advance
Re: [reiserfs-list] 2GB files don't work for me
David Lloyd wrote:
Hi there!
Does the problem lie with tar/dd/etc?
You could try:
#! /usr/bin/perl
my $count;
while ($count++ [a number of bytes]) {
`echo 1 some_file.test`
}
That could eliminate the dd, tar thing.
Yes, but dd should also work, even if one can avoid using it :)
Actually, Krys have hit an old bug in reiserfs which showed itself only
with first hunk of
ftp://ftp.namesys.com/pub/reiserfs-for-2.4/2.4.7.pending/2.4.7-plug-hole-and-pap-5660-pathrelse-fixes.dif,
which was going to clean up the code a bit.
Thanks,
vs
You could probably implement
that algorithm in bash/csh but I can't be bothered working out how to
compare numbers in bash ;-P
DSL
--
User:Is Windows a real operating system?
MegaHal: It is a free operating system.
- Quoting megahal (download: http://megahal.sourceforge.net/)
Re: [reiserfs-list] Re: still no reiserfs-patch in 2.4.10-pre2
On 08/31/2001 04:37 AM, Dieter Nützel wrote: Nikita Danilov wrote: Hans Reiser wrote: [-] You did not send it to him since the last release by him, so you have not sent it to him by his rules. We don't get to make the rules, we just get to play. I did send them to him *four* times, each time after he released new kernel. No effect. I don't see how current situation is different, but I shall try anyway. Why do you don't sent a copy to Alan? Got them. Running 2.4.10-pre2 with all of them plus 2.4.9 - unsent. When will we see this? 2.4.7-unlink-truncate-rename-rmdir.dif If this is still needed for using VMware I'll need this before attempting to use kernels 2.4.8 :-( I'm currently running 2.4.8 with Vladimirs patch for 2.4.7 and it's working very well. No stability issues on my side ;-)) What about Chris' updated transaction tracking patch for 2.4.8, see [reiserfs-list] [PATCH] improve reiserfs O_SYNC and fsync speeds from 08/14/2001 ? Did it get into the kernel or is it included in one of the recent patches? 2.4.7-plug-hole-and-pap-5660-pathrelse-fixes.dif Thanks, Dieter Thanks, Manuel
Re: [reiserfs-list] Errors in a reiserfs that hagns out my machine
Apologize me about my ignorance, but with this procedure can be any data lost?.. I don't have any other 260GB to make a backup. If this procedure is safe, I will do it immediatly and send you the reports. debugreiserfs does not change the data, just extract and pack the metadata, which we unpack to the file. Then you run fsck on the file, what does not change the partition also. If this finishes w/out any problem you can even losetup /dev/loop0 somefile-on-non-reiserfs mount /dev/loop0 /mnt-point and take a look at what was recovered. If result satisfies you, you can run it at your partition, it should work in the same way. If not, write me about your problems. -- Thanks, Vitaly Fertman Hi, you have to rebuild your partition. Usually we recommend to dd the parttion somewhere, but I do not think you have another 260G, so I would recommend to run : touch somefile-on-non-reiserfs 3.x.0j/debugreiserfs -p .bitmap /dev/xxx | 3.x.0j/unpack somefile-on-non-reiserfs and 3.x.0k-pre9/reiserfsck --rebuild-tree -l logfile somefile-on-non-reiserfs If it works OK, run rm somefile-on-non-reiserfs 3.x.0k-pre9/reiserfsck --rebuild-tree -l logfile /dev/xxx If not, send me the logfile and describe details. NOTE: the file somefile-on-non-reiserfs contains just metadata of files, and will take much less space. Ok, sorry for not include a complete information, I am running in a RH 7.1 distribution and using an 2.4.6 kernel with no patches or fixes... I have just downloaded the reiserfsprogs 3.x.0k-pre9 and cheked the partition.. The reiserfsck log reported that: bad_leaf: block 45031 has invalid item 4: 67 160 0x1 DIR (3), len 1672, location 888 entry count 66, fsck need 0, format old bad_leaf: block 562713 has invalid item 3: 57770 57716 0x1 DIR (3), len 1608, location 2304 entry count 43, fsck need 0, format old check_semantic_pass: hash mismatch detected (cic-2dm1.r24-missing) check_semantic_pass: hash mismatch detected (ih.foopre-tmp) umm, does reiserfsck detect and mark bad blocks in hds or fix them? Thanks again -- Thanks, Vitaly Fertman
[reiserfs-list] inodes under reiserfs
hi, i am newbie hier and have one stupide question. how do i know how many inode have my reiserfs patition ? for example with: df -i thanks shahram
Re: [reiserfs-list] inodes under reiserfs
Kaeidinejad, Shahram writes: hi, i am newbie hier and have one stupide question. how do i know how many inode have my reiserfs patition ? for example with: df -i Reiserfs doesn't have predefined maximal number of inodes. It's only limited by disk space. There cannot be more than 2^32 inode at the same time, though. thanks shahram Nikita.
Re: [reiserfs-list] Warm reboot issue.
Thomas T. Soares writes: Greetings all. Since 2.4.x and reiserfs I have been experiencing warm reboots with my home system. I was blaming user space progs (suspecting of Mozzila). After discart this I started to use the AC kernel series. The problem remains... Now this system is runnig at ext2 again to test, but I suspect too about this: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 196). Does anyone here recall sutch kind of behavior associated with reiserfs? No opps, no warm, nothing but a random warm reboot. Do you have CONFIG_PCI_QUIRKS on? If, yes, try to turn it off and take a look at http://namesys.com/faq.html#VIA_MVP3 Thank you. Nikita. -- | Thomas Tschoepke Soares | // Mate do | icq [EMAIL PROTECTED] |(~~~//'~) estrivo bendito |--UIN:961141---| \ / Amargo que | The fact is a secondary aspect of reality | `\_/' a gente bebe...
Re: [reiserfs-list] Pingpong-Journaling in reiser4?
Xuan Baldauf writes: Hello Hans, are you considering pingpong-journaling for reiser4? Ping-Pong journaling is that, in the case you are able to know that the blocks you are writing to will be overwritten due to outstanding requests|future transactions, you do not write the invalidation block of the old transaction until the affected blocks are overwritten by the new transaction. Doing journaling in that way, you are bringing the count of required writes for journaling to the count of required writes for non-journaling (1 changed block, 1 write instead of 1 changed block, 1 write to the journal and 1 write to the real location), and thus saving half the journal-related writes in the ideal case. The superblock is a good candidate for this feature. In reiserfs journalling written by Chris, transactions are batched that is, sequence of transactions is accumulated in memory and then dumped to journal area at once. If block was modified several times during batch, it'll be written only once, so, in some sense, reiserfs does have ping-pong journalling already. I think that heavily loaded servers with parallel disk writes will be able to see a considerable speedup. Xuân. Nikita.
Re: [reiserfs-list] Pingpong-Journaling in reiser4?
Nikita Danilov wrote: Xuan Baldauf writes: Hello Hans, are you considering pingpong-journaling for reiser4? Ping-Pong journaling is that, in the case you are able to know that the blocks you are writing to will be overwritten due to outstanding requests|future transactions, you do not write the invalidation block of the old transaction until the affected blocks are overwritten by the new transaction. Doing journaling in that way, you are bringing the count of required writes for journaling to the count of required writes for non-journaling (1 changed block, 1 write instead of 1 changed block, 1 write to the journal and 1 write to the real location), and thus saving half the journal-related writes in the ideal case. The superblock is a good candidate for this feature. In reiserfs journalling written by Chris, transactions are batched that is, sequence of transactions is accumulated in memory and then dumped to journal area at once. If block was modified several times during batch, it'll be written only once, so, in some sense, reiserfs does have ping-pong journalling already. Yes, but I don't think that this is the same. Batching makes parallel writes of different processes more efficient, pingpong-journaling also makes serial writes of the same process more efficient (e.g. a mv over a large directory, or an rpm install, etc.). Usually, metadata changes should have been synced to disk before the filesystem call returns. Without pingpong-journaling, the situation is as follows (maybe actually in reiserfs, it is slightly different, I do not know): call 1 start transaction 1 start transaction 1 write to journal transaction 1 commit transaction 1 write to real location transaction 1 invalidate call 1 end [some short time is elapsing where the application thinks what to do next] call 2 start transaction 2 start transaction 2 write to journal transaction 2 commit transaction 2 write to real location transaction 2 invalidate call 2 end You total in 4 writes. (Write to real location may be deferred until transaction 2 start, so response times to filesystem calls can be faster). With pingpong journaling, you can do it as follows: call 1 start transaction 1 start transaction 1 write to journal transaction 1 commit call 1 end [some short time is elapsing where the application thinks what to do next] call 2 start transaction 2 write to real location transaction 1 invalidate call 2 end You total in 2 writes. Basically, it is just delaying the transaction invalidation into some future. This possibly may require additional memory be pinned, so the user should be able to set an upper limit of the amount of memory used for this purpose to set the speed-memory-tradeoff. Batching cannot speed up serial transactions of the same process (does it?), while pingpong-journaling does. Actually, it is somewhat more tricky, because the set of blocks changed by transaction 2 may not be a subset of the set of blocks changed by transaction 1, so there must be some transaction invalidation transaction which does, when comitted, not only invalidate the transactions which previously changed the view on the blocks now changed again, but which also changes the view on the blocks now changed but not changed previously by now-invalidated transactions. I think that heavily loaded servers with parallel disk writes will be able to see a considerable speedup. Xuân. Nikita. Xuân.
Re: [reiserfs-list] Pingpong-Journaling in reiser4?
Xuan Baldauf writes: Nikita Danilov wrote: Xuan Baldauf writes: Hello Hans, are you considering pingpong-journaling for reiser4? Ping-Pong journaling is that, in the case you are able to know that the blocks you are writing to will be overwritten due to outstanding requests|future transactions, you do not write the invalidation block of the old transaction until the affected blocks are overwritten by the new transaction. Doing journaling in that way, you are bringing the count of required writes for journaling to the count of required writes for non-journaling (1 changed block, 1 write instead of 1 changed block, 1 write to the journal and 1 write to the real location), and thus saving half the journal-related writes in the ideal case. The superblock is a good candidate for this feature. In reiserfs journalling written by Chris, transactions are batched that is, sequence of transactions is accumulated in memory and then dumped to journal area at once. If block was modified several times during batch, it'll be written only once, so, in some sense, reiserfs does have ping-pong journalling already. Yes, but I don't think that this is the same. Batching makes parallel writes of different processes more efficient, pingpong-journaling also makes serial writes of the same process more efficient (e.g. a mv over a large directory, or an rpm install, etc.). Usually, metadata changes should have been synced to disk before the filesystem call returns. Now as I am confused, I'll just describe how reiserfs (3.6) journalling works: Transaction batch starts call 1 starts tr1 involves blocks into transaction (no io) call 1 ends call 2 starts tr2 involves blocks into transaction (no io) call 2 ends ... call N starts trN involves blocks into transaction (no io) call N ends At that point either some predefined amount of time has elapsed, or transactions have involved more than JOURNAL_MAX_BATCH (==900) blocks. All blocks are dumped into journal area. Wait until io complete. Write commit block into journal area. Mark all blocks dirty so they will be flushed to real locations by normal means. Next transaction batch starts. How does ping-pong journalling differs from this? Nikita. Without pingpong-journaling, the situation is as follows (maybe actually in reiserfs, it is slightly different, I do not know): call 1 start transaction 1 start transaction 1 write to journal transaction 1 commit transaction 1 write to real location transaction 1 invalidate call 1 end [some short time is elapsing where the application thinks what to do next] call 2 start transaction 2 start transaction 2 write to journal transaction 2 commit transaction 2 write to real location transaction 2 invalidate call 2 end You total in 4 writes. (Write to real location may be deferred until transaction 2 start, so response times to filesystem calls can be faster). With pingpong journaling, you can do it as follows: call 1 start transaction 1 start transaction 1 write to journal transaction 1 commit call 1 end [some short time is elapsing where the application thinks what to do next] call 2 start transaction 2 write to real location transaction 1 invalidate call 2 end You total in 2 writes. Basically, it is just delaying the transaction invalidation into some future. This possibly may require additional memory be pinned, so the user should be able to set an upper limit of the amount of memory used for this purpose to set the speed-memory-tradeoff. Batching cannot speed up serial transactions of the same process (does it?), while pingpong-journaling does. Actually, it is somewhat more tricky, because the set of blocks changed by transaction 2 may not be a subset of the set of blocks changed by transaction 1, so there must be some transaction invalidation transaction which does, when comitted, not only invalidate the transactions which previously changed the view on the blocks now changed again, but which also changes the view on the blocks now changed but not changed previously by now-invalidated transactions. I think that heavily loaded servers with parallel disk writes will be able to see a considerable speedup. Xuân. Nikita. Xuân.
Re: [reiserfs-list] Pingpong-Journaling in reiser4?
Nikita Danilov wrote: Xuan Baldauf writes: Nikita Danilov wrote: Xuan Baldauf writes: Hello Hans, are you considering pingpong-journaling for reiser4? Ping-Pong journaling is that, in the case you are able to know that the blocks you are writing to will be overwritten due to outstanding requests|future transactions, you do not write the invalidation block of the old transaction until the affected blocks are overwritten by the new transaction. Doing journaling in that way, you are bringing the count of required writes for journaling to the count of required writes for non-journaling (1 changed block, 1 write instead of 1 changed block, 1 write to the journal and 1 write to the real location), and thus saving half the journal-related writes in the ideal case. The superblock is a good candidate for this feature. In reiserfs journalling written by Chris, transactions are batched that is, sequence of transactions is accumulated in memory and then dumped to journal area at once. If block was modified several times during batch, it'll be written only once, so, in some sense, reiserfs does have ping-pong journalling already. Yes, but I don't think that this is the same. Batching makes parallel writes of different processes more efficient, pingpong-journaling also makes serial writes of the same process more efficient (e.g. a mv over a large directory, or an rpm install, etc.). Usually, metadata changes should have been synced to disk before the filesystem call returns. Now as I am confused, I'll just describe how reiserfs (3.6) journalling works: Transaction batch starts call 1 starts tr1 involves blocks into transaction (no io) call 1 ends call 2 starts tr2 involves blocks into transaction (no io) call 2 ends ... call N starts trN involves blocks into transaction (no io) call N ends At that point either some predefined amount of time has elapsed, or transactions have involved more than JOURNAL_MAX_BATCH (==900) blocks. All blocks are dumped into journal area. Wait until io complete. Write commit block into journal area. Mark all blocks dirty so they will be flushed to real locations by normal means. Next transaction batch starts. So, while metadata changes are atomic, they are not synchronous? How does ping-pong journalling differs from this? It is only for the synchronous case, where applications wait until the changes reach the disk (maybe due to fsync and friends). So if the asynchronous case is the normal case (seems so), additional pingpong-journaling does not seem to have a large impact. When intensive data journaling is needed (which is about to be enabled in reiser4?), the impact may become greater due to the higher frequency of commit-blocks. Nikita. Without pingpong-journaling, the situation is as follows (maybe actually in reiserfs, it is slightly different, I do not know): call 1 start transaction 1 start transaction 1 write to journal transaction 1 commit transaction 1 write to real location transaction 1 invalidate call 1 end [some short time is elapsing where the application thinks what to do next] call 2 start transaction 2 start transaction 2 write to journal transaction 2 commit transaction 2 write to real location transaction 2 invalidate call 2 end You total in 4 writes. (Write to real location may be deferred until transaction 2 start, so response times to filesystem calls can be faster). With pingpong journaling, you can do it as follows: call 1 start transaction 1 start transaction 1 write to journal transaction 1 commit call 1 end [some short time is elapsing where the application thinks what to do next] call 2 start transaction 2 write to real location transaction 1 invalidate call 2 end You total in 2 writes. Basically, it is just delaying the transaction invalidation into some future. This possibly may require additional memory be pinned, so the user should be able to set an upper limit of the amount of memory used for this purpose to set the speed-memory-tradeoff. Batching cannot speed up serial transactions of the same process (does it?), while pingpong-journaling does. Actually, it is somewhat more tricky, because the set of blocks changed by transaction 2 may not be a subset of the set of blocks changed by transaction 1, so there must be some transaction invalidation transaction which does, when comitted, not only invalidate the transactions which previously changed the view on the blocks now changed again, but which also changes the view on the blocks now changed but not changed previously by now-invalidated transactions. I think that heavily
Re: [reiserfs-list] File Corruption and Network Disconnects?
Hi Tony Willoughby wrote: I've got a system with corrupted files. I can't figure out who the culprit is, DRBD or reiserFS. Here's my configuration: - Two nodes running Red Hat 6.1 - DRBD Version: 58. Running over eth1 (10/100 ethernet). - ReiserFS version 3.5.24 - Heartbeat 0.4.9. Running over eth1 and eth2 (10/100 ethernet). The two systems are called c1220 and c1220b. c1220b was reset and heartbeat on c1220 became primary, DRBD ran fsck and mounted the reiserFS. At least one of the files in this filesystem was corrupt. Did you find that contents of file changed? Was it old file which was not updated recently? Between the point that heartbeat started running datadisk and fsck was run, DRBD reported the network disconnect. Could this be a clue? Another odd thing, before the failover when c1220 was coming up, DRBD reported this: Aug 27 08:22:15 c1220 kernel: eth1: media is 100Mb/s. Aug 27 08:22:15 c1220 kernel: eth2: media is 100Mb/s. Aug 27 08:22:15 c1220 kernel: drbd: module initialised. Version: 58 Aug 27 08:22:15 c1220 kernel: eth0: media is 100Mb/s. Aug 27 08:22:15 c1220 kernel: drbd0: user provided size = 2048728 KB Aug 27 08:22:15 c1220 kernel: drbd : vmallocing 64022 B for bitmap. @d086a01c Aug 27 08:22:15 c1220 kernel: drbd0: Connection established. Aug 27 08:22:15 c1220 kernel: drbd0: size=2048728 KB / blksize=4096 B Aug 27 08:22:15 c1220 kernel: drbd0: magic?? m: 942551345 c: 11826 l: 11825 Aug 27 08:22:15 c1220 kernel: drbd0: Connection lost.(pc=0,uc=0) Aug 27 08:22:15 c1220 kernel: drbd0: Connection established. Aug 27 08:22:15 c1220 kernel: drbd0: size=2048728 KB / blksize=4096 B Aug 27 08:22:15 c1220 kernel: drbd0: sock_sendmsg returned -32 Aug 27 08:22:15 c1220 kernel: drbd0: sock_recvmsg returned -32 Aug 27 08:22:15 c1220 kernel: drbd0: Connection lost.(pc=0,uc=0) Aug 27 08:22:15 c1220 kernel: drbd0: Connection established. Aug 27 08:22:15 c1220 kernel: drbd0: size=2048728 KB / blksize=4096 B Aug 27 08:22:13 c1220 adc_version: PID=831 The connection lost/established/lost/established is not reflected in the peer's log. Below are the logs for c1220 when the corruption occured: Aug 27 08:24:48 c1220 /etc/ha.d/resource.d/PreBasLcd: status - stopped Aug 27 08:24:48 c1220 heartbeat: info: Acquiring resource group: c1220 PreBasLcd datadisk BasLDAP IPaddr::192.168.221.226/24 basctlr PostBasLcd Aug 27 08:24:48 c1220 heartbeat: info: Running /etc/ha.d/resource.d/PreBasLcd start Aug 27 08:24:48 c1220 /etc/ha.d/resource.d/PreBasLcd: start Aug 27 08:24:48 c1220 heartbeat: info: Running /etc/ha.d/resource.d/datadisk start Aug 27 08:24:50 c1220 drbd: succeeded Aug 27 08:24:51 c1220 kernel: drbd0: Connection lost.(pc=0,uc=0) Aug 27 08:24:51 c1220 kernel: drbd0: user provided size = 2048728 KB Aug 27 08:24:51 c1220 drbd: succeeded Aug 27 08:24:51 c1220 datadisk: The node can become primary without waiting Aug 27 08:24:54 c1220 drbdc: succeeded Aug 27 08:24:55 c1220 drbdc: succeeded Aug 27 08:24:57 c1220 kernel: Checking ReiserFS transaction log (device 2b:00) ... Aug 27 08:25:03 c1220 kernel: Replayed 71 transactions in 6 seconds Aug 27 08:25:03 c1220 kernel: Using tea hash to sort names Aug 27 08:25:03 c1220 kernel: ReiserFS core development sponsored by SuSE Labs (suse.com) Aug 27 08:25:03 c1220 kernel: Journaling sponsored by MP3.com Aug 27 08:25:03 c1220 kernel: ReiserFS version 3.5.24 Aug 27 08:25:03 c1220 drbdc: succeeded Anyone have any thoughts on this? I do not see anything wrong with reiserfs in your logs. But that you are using old version of reiserfs. Since 3.5.24 reiserfs got a lot of major fixes including ones causing filesystem corruptions. So, you should upgrade to something more fresh from ftp.namesys.com. Thanks, vs
Re: [reiserfs-list] Errors in a reiserfs that hagns out my machine
On Aug 31, 2001 15:43 +0200, Groo, El Errante wrote: Apologize me about my ignorance, but with this procedure can be any data lost?.. I don't have any other 260GB to make a backup. If this procedure is safe, I will do it immediatly and send you the reports. What???!!! You have 260GB of data and you DON'T have a backup? Having a small bitmap error is the least of your worries then. Just because you have RAID5 does not mean your data is safe. Often, on systems that have very long uptimes, you can have multiple-disk failures if you have a long shutdown period. Also, RAID doesn't protect against user/software error that deletes some/all of your data. If you DO have a backup, then the worst that can happen (not saying it WILL happen) is that your filesystem is totally lost, so you create a new one and restore the data. An outage of a couple of hours to do a full restore is nothing compared to trying to get all of your data back if you have some sort of problem. Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Re: [reiserfs-list] Errors in a reiserfs that hagns out my machine
Andreas Dilger wrote: On Aug 31, 2001 15:43 +0200, Groo, El Errante wrote: Apologize me about my ignorance, but with this procedure can be any data lost?.. I don't have any other 260GB to make a backup. If this procedure is safe, I will do it immediatly and send you the reports. What???!!! You have 260GB of data and you DON'T have a backup? Having a small bitmap error is the least of your worries then. Just because you have RAID5 does not mean your data is safe. Often, on systems that have very long uptimes, you can have multiple-disk failures if you have a long shutdown period. Also, RAID doesn't protect against user/software error that deletes some/all of your data. If you DO have a backup, then the worst that can happen (not saying it WILL happen) is that your filesystem is totally lost, so you create a new one and restore the data. An outage of a couple of hours to do a full restore is nothing compared to trying to get all of your data back if you have some sort of problem. Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert I have worked at companies that had very fancy raid boxes for their cvs repositories, and then a controller went bad and scribbled over everything. Bad hardware can overcome almost any expenditure of money. ram goes bad, cpus go bad, and data corrupts. It happens a lot, not just on freak occasions. Hans
[reiserfs-list] Mount options
Hi I had a /etc/fstab (Linux Mandrake 7.2 - kernel 2.2.17) that contained the following lines : /dev/hda3 / reiserfs notail 1 1 /dev/hdb6 /ext reiserfs rw,suid,dev,exec,auto,user,async 1 2 Nothing to say about the first one. The second line contains options that i used with ext2fs. The result was that i was unable to execute nothing on the /ext filesystem (scripts or binaries). I rewrote the line like this : /dev/hdb6 /ext reiserfs notail 1 2 and everything works. The question is : does it exists mount options for reiserfs that does the same thing as those on ext2fs? (rw,suid,dev,exec,auto,user,async, etc). Thanks Rosaire AMORE
Re: [reiserfs-list] Mount options
On Aug 31, 2001 18:54 +0200, Rosaire AMORE wrote: /dev/hdb6 /ext reiserfs rw,suid,dev,exec,auto,user,async 1 2 The second line contains options that i used with ext2fs. The result was that i was unable to execute nothing on the /ext filesystem (scripts or binaries). I rewrote the line like this : /dev/hdb6 /ext reiserfs notail 1 2 Well, most of those options are in the defaults flag, so you could use: /dev/hdb6 /ext reiserfs defaults,user 1 2 and it should work for both filesystem types. However, I don't think any of them are specific to ext2, so reiserfs shouldn't have a problem if they are specified explicitly. I would _guess_ that all of these flags are handled by mount/VFS and neither reiserfs nor ext2 actually do anything with them, so it is strange that you would have such a problem. Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Re: [reiserfs-list] Mount options
Andreas Dilger writes: On Aug 31, 2001 18:54 +0200, Rosaire AMORE wrote: /dev/hdb6 /ext reiserfs rw,suid,dev,exec,auto,user,async 1 2 The second line contains options that i used with ext2fs. The result was that i was unable to execute nothing on the /ext filesystem (scripts or binaries). I rewrote the line like this : /dev/hdb6 /ext reiserfs notail 1 2 Well, most of those options are in the defaults flag, so you could use: /dev/hdb6 /ext reiserfs defaults,user 1 2 By the way, last two fields should be 0 0, see http://namesys.com/faq.html#fstab and it should work for both filesystem types. However, I don't think any of them are specific to ext2, so reiserfs shouldn't have a problem if they are specified explicitly. I would _guess_ that all of these flags are handled by mount/VFS and neither reiserfs nor ext2 actually do anything with them, so it is strange that you would have such a problem. Cheers, Andreas Nikita. --
Re: [reiserfs-list] Mount options
Hi Rosaire AMORE wrote: Hi I had a /etc/fstab (Linux Mandrake 7.2 - kernel 2.2.17) that contained the following lines : /dev/hda3 / reiserfs notail 1 1 /dev/hdb6 /ext reiserfs rw,suid,dev,exec,auto,user,async 1 2 Nothing to say about the first one. Actually, there is something: root filesystem is mounted when /etc/fstab is not available, so, I guess that this line is used only to remount root filesystem. AFAIS, option notail is ignored when reiserfs is remounted with that option. So, notail does not work here. Also, you might want to change 1 in sixth field by 0 in both records, so that fsck(8) will avoid calling to reiserfsck. The second line contains options that i used with ext2fs. The result was that i was unable to execute nothing on the /ext filesystem (scripts or binaries). I rewrote the line like this : /dev/hdb6 /ext reiserfs notail 1 2 and everything works. The question is : does it exists mount options for reiserfs that does the same thing as those on ext2fs? (rw,suid,dev,exec,auto,user,async, etc). The above mount options which are common for all filesystems should work for reiserfs. As for exec - if it does not work for reiserfs (fs gets mounted noexec) - it should not also work for ext2. At least it does not for me. Probably there is some mismatching between what bits does mount(8) set and how does kernel interpret those bits. Thanks, vs
