Re: tune2fs -E hash_alg=half_md4: safe for existing filesystems?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bryn M. Reeves wrote:
On 01/09/2013 06:18 PM, Bill Davidsen wrote:
I would try this on something you can afford to lose... I just don't see
any more info on this than you did before asking. I am curious, since I

Changing hash_alg on an existing file system sets the default hash algorithm for
newly created directories. It won't affect any existing directory inodes that
are already present (even if you remove all the files within them - you need to
remove and re-create the directory itself to switch algorithm).

File systems with mixed hash algorithms probably see a lot less testing than
either one or the other but both options have been around for quite a while now.

Thank you for the information below, I can certainly do a test and see if it makes a big difference, some testing will be needed.

You can test this easily enough on loopback devices if needed and there's no
real storage available and use debugfs to inspect the hash used for a particular
directory, e.g.:

debugfs> htree foo
Root node dump:
      Reserved zero: 0
      Hash Version: 2
      Info length: 8
      Indirect levels: 0
      Flags: 0
Number of entries (count): 2
Number of entries (limit): 124
Entry #0: Hash 0x00000000, block 1
Entry #1: Hash 0x896bc308, block 2
[...]

debugfs> htree bar
Root node dump:
      Reserved zero: 0
      Hash Version: 1
      Info length: 8
      Indirect levels: 0
      Flags: 0
Number of entries (count): 2
Number of entries (limit): 124
Entry #0: Hash 0x00000000, block 1
Entry #1: Hash 0x7aa4fee4, block 2
[...]

The hash versions are as follows:

#define EXT2_HASH_LEGACY                0
#define EXT2_HASH_HALF_MD4              1
#define EXT2_HASH_TEA                   2

It's probably somewhat more risky than re-making the file system with the
preferred hash and restoring but you could progressively migrate a file system
over (or at least do some testing to see if it's worth it or not) by copying and
renaming existing trees after changing hash_alg.

Regards,
Bryn.



--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux