public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* fs change on read-only mount
@ 2009-08-13 12:37 Bgs
  2009-08-13 13:14 ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Bgs @ 2009-08-13 12:37 UTC (permalink / raw)
  To: SGI Project XFS mailing list


 Greetings,

I don't know xfs' superblock handling well enough, so I'm asking for
advice here:

Does xfs write anything on the disk when mounting read-only? Is it
possible to use a partitions hash (or some well defined portion of the
partition) for integrity checks?

The partitions are used read-only and hash would be re-generated  if any
rw action was done (after remount ro or full reboot of course). Can this
be done? I'm concerned about 'mount count' like writes...

Thanks in advance
Bgs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fs change on read-only mount
  2009-08-13 12:37 fs change on read-only mount Bgs
@ 2009-08-13 13:14 ` Christoph Hellwig
  2009-08-13 13:47   ` Bgs
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2009-08-13 13:14 UTC (permalink / raw)
  To: Bgs; +Cc: SGI Project XFS mailing list

On Thu, Aug 13, 2009 at 02:37:30PM +0200, Bgs wrote:
> 
>  Greetings,
> 
> I don't know xfs' superblock handling well enough, so I'm asking for
> advice here:
> 
> Does xfs write anything on the disk when mounting read-only? Is it
> possible to use a partitions hash (or some well defined portion of the
> partition) for integrity checks?

It should not write anything to disk [1], but older versions did so due to
bugs.  Doing a hash of a read-only filesystem should be fine.

> The partitions are used read-only and hash would be re-generated  if any
> rw action was done (after remount ro or full reboot of course). Can this
> be done? I'm concerned about 'mount count' like writes...

There is no mount-count like write in XFS.

[1] the only exception is that log reocvery is performed when we attempt 
    a read-only mount with an unclean log, that is the box crashed while
    writing the filesystems.  To make sure you never do this always mark
    the underlying device readonly, using blkdev --ro.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fs change on read-only mount
  2009-08-13 13:14 ` Christoph Hellwig
@ 2009-08-13 13:47   ` Bgs
  2009-08-13 13:49     ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Bgs @ 2009-08-13 13:47 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: SGI Project XFS mailing list


 Thanks for the fast answer.

So the following scenarios should be ok:

1) Normal boot (no crash, previous mount was ro as well, journal empty)
-> mount ro from the beginning => partition hash stays the same

2) Mount rw at any point -> make changes -> remount ro -> sync -> create
 new hash -> next boot with ro mount has this new hash.

Regards
Bgs


Christoph Hellwig wrote:
> On Thu, Aug 13, 2009 at 02:37:30PM +0200, Bgs wrote:
>>  Greetings,
>>
>> I don't know xfs' superblock handling well enough, so I'm asking for
>> advice here:
>>
>> Does xfs write anything on the disk when mounting read-only? Is it
>> possible to use a partitions hash (or some well defined portion of the
>> partition) for integrity checks?
> 
> It should not write anything to disk [1], but older versions did so due to
> bugs.  Doing a hash of a read-only filesystem should be fine.
> 
>> The partitions are used read-only and hash would be re-generated  if any
>> rw action was done (after remount ro or full reboot of course). Can this
>> be done? I'm concerned about 'mount count' like writes...
> 
> There is no mount-count like write in XFS.
> 
> [1] the only exception is that log reocvery is performed when we attempt 
>     a read-only mount with an unclean log, that is the box crashed while
>     writing the filesystems.  To make sure you never do this always mark
>     the underlying device readonly, using blkdev --ro.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fs change on read-only mount
  2009-08-13 13:47   ` Bgs
@ 2009-08-13 13:49     ` Christoph Hellwig
  0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2009-08-13 13:49 UTC (permalink / raw)
  To: Bgs; +Cc: SGI Project XFS mailing list

On Thu, Aug 13, 2009 at 03:47:08PM +0200, Bgs wrote:
> 
>  Thanks for the fast answer.
> 
> So the following scenarios should be ok:
> 
> 1) Normal boot (no crash, previous mount was ro as well, journal empty)
> -> mount ro from the beginning => partition hash stays the same
> 
> 2) Mount rw at any point -> make changes -> remount ro -> sync -> create
>  new hash -> next boot with ro mount has this new hash.

Yes.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-08-13 13:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-13 12:37 fs change on read-only mount Bgs
2009-08-13 13:14 ` Christoph Hellwig
2009-08-13 13:47   ` Bgs
2009-08-13 13:49     ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox