Re: Mounting a filesystem *really* read-only
Ted Rodriguez-Bell wrote: As the poser of the original question, I'd like to thank everyone who took the trouble to answer. There were far more answers than I expected and a lot of things brought up that I hadn't thought of. We like a good argument;-) -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
Binyamin Dissen wrote: On Tue, 16 Jun 2009 08:37:55 +0200 Rob van der Heij wrote: :>There's nothing in the S/390 I/O architecture that supports the :>concept of R/O disks (unlike tapes). If I recall correctly, there used to be switches to make a disk read-only. That is true. It's also true that Linux can handle ro ext2 filesystems, I have mounted them from cd. -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
As the poser of the original question, I'd like to thank everyone who took the trouble to answer. There were far more answers than I expected and a lot of things brought up that I hadn't thought of. Ted Rodriguez-Bell Enterprise Virtualization - z/VM and z/Linux te...@wellsfargo.com, 415-243-6291 -- Company policy requires: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
On Tue, Jun 16, 2009 at 2:24 PM, Alan Altmark wrote: > Sure it is. Command Reject + Write Inhibited. Older drives had a > physical "R/O" switch on them. It could also show up on more recent > drives as Equipment Check + Write Inhibited, indicating that the host has > set a logical R/O condition in the drive. And I also noticed there are CCW's to set and clear the "write inhibit" - but the point is that there is nothing in the Sense ID that will tell you before you write to the device. But my world is small enough that it is enough that DIAG210 has a bit to tell.I don't know (anymore) why the Linux driver does not use that. -Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
On Tuesday, 06/16/2009 at 02:39 EDT, Rob van der Heij wrote: > There's nothing in the S/390 I/O architecture that supports the > concept of R/O disks (unlike tapes). Sure it is. Command Reject + Write Inhibited. Older drives had a physical "R/O" switch on them. It could also show up on more recent drives as Equipment Check + Write Inhibited, indicating that the host has set a logical R/O condition in the drive. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
On Tue, 16 Jun 2009 08:37:55 +0200 Rob van der Heij wrote: :>There's nothing in the S/390 I/O architecture that supports the :>concept of R/O disks (unlike tapes). If I recall correctly, there used to be switches to make a disk read-only. Is that no longer true? If it is true, shouldn't sense provide the information? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
On Tue, Jun 16, 2009 at 4:19 AM, Scott Rohling wrote: > Ditto.. especially coming from the wonders of z/VM link modes (e.g. MR > seems like what we want here) as we VMers have.. With all respect, the VM link mode has nothing to do with this. That's merely part of why you ended having the disk RW or RO. > On Mon, Jun 15, 2009 at 6:58 PM, Richard Troth wrote: > >> I have never understood why the driver does not automatically set the >> R/O flag when a write operation is rejected. That would be late. At that point the page cache holds a page with (different) contents that is presented to processes as the contents of that block on disk, which it maybe is not. Given the lazy write, people would already have been using the wrong data for 30 seconds before you get notified. There's nothing in the S/390 I/O architecture that supports the concept of R/O disks (unlike tapes). It would be possible to create such an interface and define a bit in the device info diagnose that Linux is using already (to parse the output of Q V is not really nice). Clearly this would only work for Linux on z/VM, but the issue does not really apply to LPAR anyway. But maybe Carsten still knows why we did not think that was an option. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
Ditto.. especially coming from the wonders of z/VM link modes (e.g. MR seems like what we want here) as we VMers have.. Scott On Mon, Jun 15, 2009 at 6:58 PM, Richard Troth wrote: > I have never understood why the driver does not automatically set the > R/O flag when a write operation is rejected. > > > -- R; <>< > > > > > > 2009/6/15 Carsten Otte : > > Am Sun, 14 Jun 2009 01:34:35 +0200 > > schrieb Rob van der Heij : > >> One of the problems is that S/390 has no way to sense the R/O setting > >> of the disk, so we can't pass that to the mount (like you have with a > >> CD for example). The only way to tell is by trying to write to the > >> disk.We did not think that was very elegant. > >> > >> But you can also tell the Linux dasd driver to not write it, that > >> should be more powerful than mount ro. It's probably through the > >> hwcfg-* files. I believe that with that setting the mount will default > >> to "ro" ? > > You recall correctly. The parameter can also be set via the (ro) > > suffix on dasd parameter line either as parameter to insmod when > > loading dasd, or via kernel parameter (zipl). Like this: > > dasd=1000,1001(ro),2000-20ff(ro) > > ^^ dasd 1000 will be writable, 1001 and 2000-20ff are read only. > > > > All mounts of subject dasds will be read-only by default. The > > parameter can be changed using the blockdev command (--setro option)*. > > > > * make sure you're not setting a disk to read-only that is currently > > mounted read+write > > > > -- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
I have never understood why the driver does not automatically set the R/O flag when a write operation is rejected. -- R; <>< 2009/6/15 Carsten Otte : > Am Sun, 14 Jun 2009 01:34:35 +0200 > schrieb Rob van der Heij : >> One of the problems is that S/390 has no way to sense the R/O setting >> of the disk, so we can't pass that to the mount (like you have with a >> CD for example). The only way to tell is by trying to write to the >> disk.We did not think that was very elegant. >> >> But you can also tell the Linux dasd driver to not write it, that >> should be more powerful than mount ro. It's probably through the >> hwcfg-* files. I believe that with that setting the mount will default >> to "ro" ? > You recall correctly. The parameter can also be set via the (ro) > suffix on dasd parameter line either as parameter to insmod when > loading dasd, or via kernel parameter (zipl). Like this: > dasd=1000,1001(ro),2000-20ff(ro) > ^^ dasd 1000 will be writable, 1001 and 2000-20ff are read only. > > All mounts of subject dasds will be read-only by default. The > parameter can be changed using the blockdev command (--setro option)*. > > * make sure you're not setting a disk to read-only that is currently > mounted read+write > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
Am Sun, 14 Jun 2009 01:34:35 +0200 schrieb Rob van der Heij : > One of the problems is that S/390 has no way to sense the R/O setting > of the disk, so we can't pass that to the mount (like you have with a > CD for example). The only way to tell is by trying to write to the > disk.We did not think that was very elegant. > > But you can also tell the Linux dasd driver to not write it, that > should be more powerful than mount ro. It's probably through the > hwcfg-* files. I believe that with that setting the mount will default > to "ro" ? You recall correctly. The parameter can also be set via the (ro) suffix on dasd parameter line either as parameter to insmod when loading dasd, or via kernel parameter (zipl). Like this: dasd=1000,1001(ro),2000-20ff(ro) ^^ dasd 1000 will be writable, 1001 and 2000-20ff are read only. All mounts of subject dasds will be read-only by default. The parameter can be changed using the blockdev command (--setro option)*. * make sure you're not setting a disk to read-only that is currently mounted read+write -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
On Sun, Jun 14, 2009 at 1:16 AM, John Summerfield wrote: > The original question said "LPAR." Until I recalled that, I was going to > suggest making the DASD RO in VM. One of the problems is that S/390 has no way to sense the R/O setting of the disk, so we can't pass that to the mount (like you have with a CD for example). The only way to tell is by trying to write to the disk.We did not think that was very elegant. But you can also tell the Linux dasd driver to not write it, that should be more powerful than mount ro. It's probably through the hwcfg-* files. I believe that with that setting the mount will default to "ro" ? -Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
van Sleeuwen, Berry wrote: Be aware that if you do use reserve/release you *MUST* set the DASD to shared if you are running in multiple VM's. At the very least the one The original question said "LPAR." Until I recalled that, I was going to suggest making the DASD RO in VM. where you put the lock file. If you don't you will get problems with locking DASD devices. As we experienced with our VSE systems a few years back. One of 4 VM's held the lock on the DASD containing the VSE lock file preventing other VSE systems access to this DASD. Regards, Berry. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
Mark Post wrote: On 6/8/2009 at 7:38 PM, Shane Ginnane wrote: If the access will truly be read-only, then mount the file system as ext2, and not ext3. I don't believe that will work if the dirty flag is on - which it will be if you are worried about journal replay on (re-)mount. It will work as long as you don't try to run fsck against it. The file system driver will whine, but it will mount it. Creating the fs as ext2 might be sensible. Back around when Shane and I shared an office, disk drives had write-enable switches. Is making the drive RO still possible? -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
>>> On 6/8/2009 at 11:18 PM, Shane Ginnane wrote: -snip- > If you attempt to mount a *clean* ext3 f/s as ext2 you get the warning - > and a successful mount. > With a dirty journal it refuses to mount as ext2 (ro *or* rw). So, make the file system really be ext2, and not ext3. If all they're looking for is a quick fix to a short-term problem, a very small minidisk would suffice for the "flag." Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
Mark wrote on 09/06/2009 11:02:22 AM: > > Second (as Mark noted) - you may think you can mount the FS R/O and prevent > > the log from being replayed by specifying you want a non-journaled FS (aka > > EXT2) - which may (and will) lead to the FS being marked dirty (as Shane > > noted) - requiring a 'fsck' to be performed - requiring WRITE access (bad.. > > very bad !) > > The fsck is _not_ required, so write access is not required. Sorry Mark, I'm in agreement with Ivan. I just did a test on x86 as at the moment I don't have a zLinux system I can break filesystems on. If you attempt to mount a *clean* ext3 f/s as ext2 you get the warning - and a successful mount. With a dirty journal it refuses to mount as ext2 (ro *or* rw). A subsequent mount as ext3 (ro) runs the journal regardless as has been discussed I think. It shows as ro in /proc/mounts. Shane ... -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
>>> On 6/8/2009 at 8:02 PM, Ivan Warren wrote: > Second (as Mark noted) - you may think you can mount the FS R/O and prevent > the log from being replayed by specifying you want a non-journaled FS (aka > EXT2) - which may (and will) lead to the FS being marked dirty (as Shane > noted) - requiring a 'fsck' to be performed - requiring WRITE access (bad.. > very bad !) The fsck is _not_ required, so write access is not required. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
Ted Rodriguez-Bell wrote: The first thing we tried was just to have B mount the disks read-only and check for a flag file; if that file (we'll call it IN_USE) exists, don't do anything. If it doesn't, then A has shut down nicely and it's safe to grab the filesystem read-only. Hrmm... Wait a minute ! Are you saying side A is using the filesystem R/W and you are attempting to mount the filesystem on side B R/O ? And *THEN* you are trying to see any modifications made on side A from side B ? That's very *VERY* unreliable ! First, as you noted, ext3 is a journaled filesystem.. So this means that any changes made by side A only have meaning if you can replay the log. Second (as Mark noted) - you may think you can mount the FS R/O and prevent the log from being replayed by specifying you want a non-journaled FS (aka EXT2) - which may (and will) lead to the FS being marked dirty (as Shane noted) - requiring a 'fsck' to be performed - requiring WRITE access (bad.. very bad !) Third.. If you mount the fs R/O and read data off of it - there is NO GUARANTEE - that the FS manager will reread that very same block if it is already cached.. So your view of the FS is likely going to be skewed.. Or you could be reading something completely different and unrelated... Which in the event you are trying to read an hyperblock, alloc map or other forms of meta data, could lead to a system panic if the system believes the FS has gone completely insane (which it could since it cannot relate the changes made by side A). ... ext2 and/or ext3 is (as I see it) never been designed to be used with concurrent access in mind. Personally, I would *NOT* tread in those waters (whatever the architecture !) I would strongly suggest you use a filesystem that is designed to be accessed concurrently by multiple systems (OCFS2 maybe ?) --Ivan -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 smime.p7s Description: S/MIME Cryptographic Signature
Re: Mounting a filesystem *really* read-only
>>> On 6/8/2009 at 7:38 PM, Shane Ginnane wrote: >> If the access will truly be read-only, then mount the file system as >> ext2, and not ext3. > > I don't believe that will work if the dirty flag is on - which it will be > if you are worried about journal replay on (re-)mount. It will work as long as you don't try to run fsck against it. The file system driver will whine, but it will mount it. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
> If the access will truly be read-only, then mount the file system as > ext2, and not ext3. I don't believe that will work if the dirty flag is on - which it will be if you are worried about journal replay on (re-)mount. Shane ... -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
You forgot one :) - Must not use GDPS Hyperswap. Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Alan Altmark Sent: Monday, June 08, 2009 6:28 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Mounting a filesystem *really* read-only On Monday, 06/08/2009 at 05:09 EDT, "van Sleeuwen, Berry" wrote: > Be aware that if you do use reserve/release you *MUST* set the DASD to > shared if you are running in multiple VM's. Reminder of cross-system Reserve/Release requirements for minidisks: - Must be a full-pack minidisk - MDISK must define disk with mode MWV - SYSTEM CONFIG must define the volume as SHARED Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
On Monday, 06/08/2009 at 05:09 EDT, "van Sleeuwen, Berry" wrote: > Be aware that if you do use reserve/release you *MUST* set the DASD to > shared if you are running in multiple VM's. Reminder of cross-system Reserve/Release requirements for minidisks: - Must be a full-pack minidisk - MDISK must define disk with mode MWV - SYSTEM CONFIG must define the volume as SHARED Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
Be aware that if you do use reserve/release you *MUST* set the DASD to shared if you are running in multiple VM's. At the very least the one where you put the lock file. If you don't you will get problems with locking DASD devices. As we experienced with our VSE systems a few years back. One of 4 VM's held the lock on the DASD containing the VSE lock file preventing other VSE systems access to this DASD. Regards, Berry. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
Re: Mounting a filesystem *really* read-only
Am Fri, 5 Jun 2009 16:47:15 -0700 schrieb Ted Rodriguez-Bell : > Now I think we could work around this by changing the device to > read-only before mounting, so you'd do something like this: > blockdev --setro /dev/dasdXX # Lock the device > if mount /dev/dasdXX /mount/point ; then > if [[ ! -f /mount/point/IN_USE ]]; then > SAFE_TO_MOUNT=yes > else > SAFE_TO_MOUNT='no, lock file exists' > fi > else > SAFE_TO_MOUNT='no, could not mount filesystem' > fi > blockdev --setrw /dev/dasdXX > I've tested "blockdev --setro" and it *is* local; changing it on one > machine doesn't change the filesystem on the other. > > But is there some other reason to think this might be unsafe? Would > Novell support be a better forum than this one? Using a lock file on the filesystem looks racy to me. Did you consider using the reserve/release feature for dasds for this? In case of unexpected crash, you could break the lock and recover the filesystem once you're sure the system that was holding the lock has died indeed. so long, Carsten -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
>>> On 6/5/2009 at 7:47 PM, Ted Rodriguez-Bell wrote: -snip- > The situation is that we have a user who can't take downtime when his > LPAR is IPLed. Despite your statement that a clustered file system would be overkill, it sounds like this user has the business requirement for an HA cluster. If he really does, then he should be using just that, and paying you for it. -snip- > The problem is that Ext3 will happily write to a filesystem *EVEN* > when you mount the FS read-only, if it thinks the journal needs > replaying. Obviously playing the journal on server B while server A > is writing to it could be Very Bad. If the access will truly be read-only, then mount the file system as ext2, and not ext3. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mounting a filesystem *really* read-only
why not use something like heartbeat when Server A goes away either planned or unplanned outage Server B mounts the filesystem. then Server A comes back Server B unmounts it and Server A mounts it I think it would be allot cleaner and only one server has it mounted at a time IMHO a better way William 'Doug' Carroll Mainframe Systems Eng Sr I Global Technology Infrastructure -Original Message- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Ted Rodriguez-Bell Sent: Friday, June 05, 2009 7:47 PM To: LINUX-390@VM.MARIST.EDU Subject: Mounting a filesystem *really* read-only Gentle managers: We have a need to mount a filesystem without reading it at all. The situation is that we have a user who can't take downtime when his LPAR is IPLed. Our workaround is to give him two servers on different LPARs, but share the same physical disks between them. Server A on LPAR AA is the primary; then A goes down then server B is directed to mount the disks and carry on. The first thing we tried was just to have B mount the disks read-only and check for a flag file; if that file (we'll call it IN_USE) exists, don't do anything. If it doesn't, then A has shut down nicely and it's safe to grab the filesystem read-only. The problem is that Ext3 will happily write to a filesystem *EVEN* when you mount the FS read-only, if it thinks the journal needs replaying. Obviously playing the journal on server B while server A is writing to it could be Very Bad. This is a known property of ext3; there was a long discussion (http://lkml.indiana.edu/hypermail/linux/kernel/0704.1/0098.html) about changing this on the kernel developers' list that petered out. The concern was that the kernel could get confused if the mount -ro proceeded and the filesystem was incorrect. Now I think we could work around this by changing the device to read-only before mounting, so you'd do something like this: blockdev --setro /dev/dasdXX # Lock the device if mount /dev/dasdXX /mount/point ; then if [[ ! -f /mount/point/IN_USE ]]; then SAFE_TO_MOUNT=yes else SAFE_TO_MOUNT='no, lock file exists' fi else SAFE_TO_MOUNT='no, could not mount filesystem' fi blockdev --setrw /dev/dasdXX I've tested "blockdev --setro" and it *is* local; changing it on one machine doesn't change the filesystem on the other. But is there some other reason to think this might be unsafe? Would Novell support be a better forum than this one? (And we don't want to mess with a clustered filesystem if we don't have to; they'd work but for this it would be overkill.) Gratefully yours, Ted Rodriguez-Bell te...@wellsfargo.com -- Company policy requires: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures rela
Mounting a filesystem *really* read-only
Gentle managers: We have a need to mount a filesystem without reading it at all. The situation is that we have a user who can't take downtime when his LPAR is IPLed. Our workaround is to give him two servers on different LPARs, but share the same physical disks between them. Server A on LPAR AA is the primary; then A goes down then server B is directed to mount the disks and carry on. The first thing we tried was just to have B mount the disks read-only and check for a flag file; if that file (we'll call it IN_USE) exists, don't do anything. If it doesn't, then A has shut down nicely and it's safe to grab the filesystem read-only. The problem is that Ext3 will happily write to a filesystem *EVEN* when you mount the FS read-only, if it thinks the journal needs replaying. Obviously playing the journal on server B while server A is writing to it could be Very Bad. This is a known property of ext3; there was a long discussion (http://lkml.indiana.edu/hypermail/linux/kernel/0704.1/0098.html) about changing this on the kernel developers' list that petered out. The concern was that the kernel could get confused if the mount -ro proceeded and the filesystem was incorrect. Now I think we could work around this by changing the device to read-only before mounting, so you'd do something like this: blockdev --setro /dev/dasdXX # Lock the device if mount /dev/dasdXX /mount/point ; then if [[ ! -f /mount/point/IN_USE ]]; then SAFE_TO_MOUNT=yes else SAFE_TO_MOUNT='no, lock file exists' fi else SAFE_TO_MOUNT='no, could not mount filesystem' fi blockdev --setrw /dev/dasdXX I've tested "blockdev --setro" and it *is* local; changing it on one machine doesn't change the filesystem on the other. But is there some other reason to think this might be unsafe? Would Novell support be a better forum than this one? (And we don't want to mess with a clustered filesystem if we don't have to; they'd work but for this it would be overkill.) Gratefully yours, Ted Rodriguez-Bell te...@wellsfargo.com -- Company policy requires: This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
