lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 02 Nov 2009 17:02:05 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Andreas Dilger <adilger@....com>
CC:	Greg Freemyer <greg.freemyer@...il.com>,
	Theodore Tso <tytso@....edu>,
	Ted Augustine <taugustine@...hpathways.com>,
	Alexey Fisher <bug-track@...her-privat.net>,
	linux-ext4@...r.kernel.org
Subject: Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption
 with 2.6.32-rc1 and upwards]

Andreas Dilger wrote:
> On 2009-11-02, at 14:59, Greg Freemyer wrote:
>> One example is a hardware raid array that creates readonly snapshots
>> or clones.  (Lots of those exist in the real world).
>>
>> So the typical backup procedure is:
>>
>> ====
>> Queisce application (databases, etc. have utils to do this.)
>>
>> Queisce filesystem (xfs_freeze -f can be done from userspace. is there
>> a ext4 util?)
>>
>> issue raid array command to create snapshot.
>>
>> release filesystem (xfs_freeze -u)
>>
>> release the app (util provided by app).
>>
>> Mount the snapshot readonly (true readonly with zero writes to the
>> block device).
>>
>> Backup the readonly snapshot (to tape, etc.).
> 
> I thought Takashi Sato was working on allowing a filesystem freeze
> ioctl from userspace?  This would hook into the filesystem-specific
> freeze code so that when the ioctl() returns the on-disk filesystem
> is fully consistent and does not even require journal replay.

That's in and done; most recent xfsprogs' xfs_freeze utility will even 
freeze non-xfs filesystems now :)  Otherwise a wrapper utility around 
the ioctl would be trivial to write.

>> I believe XFS had 2 issues related to this process when first
>> implemented in linux.
>>
>> 1) It required the UUID to be unique.  Obviously in the above scenario
>> it is not, so "mount -o nouuid" was added for xfs.
>>
>> 2) Journal replay was originally aways attempted in the above process,
>> so the "mount -o norecovery" option was added to force a true readonly
>> mount.

these days a frozen xfs fs should be consistent & not need replay.

-Eric

>> ext4 may already support mounting of readonly clones, but if not it
>> needs to before it will qualify as a data center ready filesystem.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ