On Fri, Oct 07, 2011 at 02:46:23PM +0200, Kay Sievers wrote:> On Fri, Oct 7, 2011 at 12:38, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > On Fri, 7 Oct 2011 12:28:46 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote: > > > >> What do you mean would be ugly? > > > > I have an ext4fs. It supports every possible file name allowed by POSIX > > and SuS. What name are you going to use for your ''hidden directory'' that > > won''t clash with a real file ? > > Ah, no. The label on FAT (similar on NTFS) are ''magic entries'' in the > root dir list, not a real file in the root dir. > > We need kernel support for changing a mounted fs, because, unlike > ext4, the blocks containing the strings are inside the fs, which the > kernel might change any time.It''s worth noting that there are similar issues with btrfs around changing label. A common API for it would make sense. The only btrfs patches I''ve seen to change label after mkfs-time work either as: * unmounted only, single underlying device only, pure userspace implementation * mounted only, multiple underlying devices, kernel support needed The kernel-side patches never got integrated, so we''re still unable to change the label on the majority of btrfs filesystems. Changing the UUID for the filesystem is even harder, as I think it''s written to every metadata block. I''m not sure we can do that sanely on a mounted filesystem. Hugo (just a spear-carrier from the btrfs chorus). -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Anyone using a computer to generate random numbers is, of --- course, in a state of sin.
On Fri, Oct 07, 2011 at 04:21:37PM +0100, Hugo Mills wrote:> On Fri, Oct 07, 2011 at 02:46:23PM +0200, Kay Sievers wrote: > > On Fri, Oct 7, 2011 at 12:38, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > > On Fri, 7 Oct 2011 12:28:46 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote: > > > > > >> What do you mean would be ugly? > > > > > > I have an ext4fs. It supports every possible file name allowed by POSIX > > > and SuS. What name are you going to use for your ''hidden directory'' that > > > won''t clash with a real file ? > > > > Ah, no. The label on FAT (similar on NTFS) are ''magic entries'' in the > > root dir list, not a real file in the root dir. > > > > We need kernel support for changing a mounted fs, because, unlike > > ext4, the blocks containing the strings are inside the fs, which the > > kernel might change any time. > > It''s worth noting that there are similar issues with btrfs around > changing label. A common API for it would make sense. The only btrfs > patches I''ve seen to change label after mkfs-time work either as: > > * unmounted only, single underlying device only, pure userspace > implementation > * mounted only, multiple underlying devices, kernel support needed > > The kernel-side patches never got integrated, so we''re still unable > to change the label on the majority of btrfs filesystems. > > Changing the UUID for the filesystem is even harder, as I think > it''s written to every metadata block. I''m not sure we can do that > sanely on a mounted filesystem.http://marc.info/?l=linux-btrfs&m=131161949201880&w=2 "Resetting the UUID on btrfs isn''t a quick-and-easy thing - you have to walk the entire tree and change every object. We''ve got a bad-hack in meego that uses btrfs-debug-tree and changes the UUID while it runs the entire tree, but it''s ugly as hell." That''s on an unmoutned fs. Doing it on a mounted one seems more complicated wrt to the intermediate state when there are some blocks with the old and some block wit the new UUID. The operation will take long and I don''t know if it''s better do to do it in batches (and follow usual rules for commiting a transaction every now and then), or in one go (requires: no failures, no scrub run, no devices added/removed). Counting all potential problems and practical unusability of the FS during UUID change, the off-line approach seems a better way to go. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Oct 10, 2011, at 7:18 AM, David Sterba wrote:> "Resetting the UUID on btrfs isn''t a quick-and-easy thing - you have to > walk the entire tree and change every object. We''ve got a bad-hack in > meego that uses btrfs-debug-tree and changes the UUID while it runs > the entire tree, but it''s ugly as hell."Changing the UUID is going to be harder for ext4 as well, once we integrate metadata checksums. So while it makes sense to have on-line ways of updating labels for mounted file systems it probably makes muchness sense to support it for UUIDs. I suspect what it means in practice is that it will be useful for file systems to provide fs image copying tools that also generate a new UUID while you''re at it, for use by IT administrators and embedded systems manufacturers. -- Ted-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, Oct 10, 2011 at 09:09:37AM -0400, Theodore Tso wrote:> > On Oct 10, 2011, at 7:18 AM, David Sterba wrote: > > > "Resetting the UUID on btrfs isn''t a quick-and-easy thing - you > > have to walk the entire tree and change every object. We''ve got > > a bad-hack in meego that uses btrfs-debug-tree and changes the > > UUID while it runs the entire tree, but it''s ugly as hell." > > Changing the UUID is going to be harder for ext4 as well, once we > integrate metadata checksums.And for XFS, we''re modifying the on-disk format to encode the UUID into every single piece of metadata in the filesystem. Hence changing it entails a similar problem to btrfs - an entire filesystem metadata RMW cycle.> So while it makes sense to have > on-line ways of updating labels for mounted file systems it > probably makes muchness sense to support it for UUIDs.^^^^ less Agreed.> I suspect what it means in practice is that it will be useful for > file systems to provide fs image copying tools that also generate > a new UUID while you''re at it, for use by IT administrators and > embedded systems manufacturers.Yup. xfs_admin already provides an interface for offline modification of the UUID for XFS filesytems. I.e. clone the filesytem using xfs_copy, then run xfs_admin -U generate <clone> to generate a new uuid in the cloned copy before you mount the clone.... Cheers, Dave. -- Dave Chinner david@fromorbit.com
On Thu, Oct 13, 2011 at 11:28:39AM +1100, Dave Chinner wrote:> Yup. xfs_admin already provides an interface for offline > modification of the UUID for XFS filesytems. I.e. clone the > filesytem using xfs_copy, then run xfs_admin -U generate <clone> to > generate a new uuid in the cloned copy before you mount the > clone....This is probably another thing which perhaps Ric Wheeler''s proposed "generic LVM / file system management front end" should abstract away, since every single file system has a different way of setting the UUID in an off-line way. It''s a relatively specialized feature, so I wouldn''t call it high priority to implement first. - Ted