Prev: atomically concurrent writes question
Next: Using OTP tokens on Debian
From: Camaleón on 25 Jun 2010 10:20
On Fri, 25 Jun 2010 07:42:28 -0600, Aaron Toponce wrote:

> On 06/23/2010 03:30 PM, Camaleón wrote:

>> On Wed, 23 Jun 2010 13:02:36 -0600, Aaron Toponce wrote:
>>> Whether or not these are his reasons, I can tell you why that is a
>>> wise move. UUIDs are unique to the device/filesystem. The major
>>> advantage of using UUIDs is that you don't have to worry about
>>> reordering of disks by the kernel when it sees it in a different order
>>> than previous.
>>
>> Yes, I know.
>>
>> But if the installer has setup (by its own) as default method for
>> naming devices the old one and I am not experiencing any problem with
>> that, for sure I won't change that. If it ain't broke, don't fix it.
>
> Sure. But you can also avoid breakage through proper administration.

Or you can generate further problems... who knows.

The point here is that things are working properly with the current
configuration, so why change it?

>>> This isn't recommended, because if the Linux kernel developers change
>>> drivers, and the drives become a new device (just as it happened when
>>> ditching the PATA driver for SATA, and /dev/hda became /dev/sda), your
>>> partitions/volumes won't mount. Instead, you should either be using
>>> LABELs or UUIDs.
>>
>> I know, I know... but Lenny developers decided to go this way for any
>> reason and I will respect that. I'm aware that nowadays any modern
>> distribution is using "uuid" or "id" at least in "/etc/fstab" but as I
>> said, I still have not seen any good reason to change it.
>
> So, you blindly accept what the developers think is good for your
> system?

Sure! :-)

I expect developers take the right (and conscious) decision on these kind
of issues. They know (or should be aware) better than me the keys of
every released version and the choose for going one direction or another
is theirs.

> I understand they're developers for a reason, but even
> developers make mistakes. And having "/dev/sd??" in your /etc/fstab just
> might be one of them.
>
> FWIW, when the kernel switched disk drivers from PATA to SATA for
> identifying IDE drives, I had already moved my /etc/fstab to UUIDs, and
> I didn't have a problem with the upgrade. Friends of mine, however, got
> to rescue their system, because it wouldn't boot. To each their own.

I will change it as soon as I get any problems, I promise :-)

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/pan.2010.06.25.14.14.34(a)gmail.com
From: Daniel Barclay on 2 Jul 2010 14:00
Aaron Toponce wrote:

> UUIDs are unique to the device/filesystem.

Are these (disk) UUIDs stored somewhere in the partition (in the
filesystem), or are they stored at or generated from a lower level?

In particular, if one used dd to copy the contents (a file system) of
one partition to another partition, does the target partition end up
with the same UUID or a different UUID? If you did a byte-for-byte
copy of an entire disk to another disk of the exact same size (and
model, but different serial number), would the UUIDs of partitions
change or still be the same on the target disk?)

(Is it similar to, or different than, the situation with filesystem
labels (specifically, that if you copied a partition as above you'd
end up with two partitions with the same label, and you'd have to
change one (or otherwise deal with the non-uniqueness))?)

Thanks,
Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4C2E249C.6090109(a)fgm.com
From: Ron Johnson on 2 Jul 2010 14:10
On 07/02/2010 12:40 PM, Daniel Barclay wrote:
> Aaron Toponce wrote:
>
>> UUIDs are unique to the device/filesystem.
>
> Are these (disk) UUIDs stored somewhere in the partition (in the
> filesystem), or are they stored at or generated from a lower level?

In the superblock.

# dumpe2fs -h /dev/mapper/main_huge_vg-main_huge_lv
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name: BIG_LV
Last mounted on: /data/big
Filesystem UUID: 4efe50a9-0915-4022-8446-a036607492b7
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode
dir_index filetype needs_recovery extent flex_bg sparse_super
large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 241491968
Block count: 965967872
Reserved block count: 48298393
Free blocks: 323162178
Free inodes: 241184065
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 793
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Thu Jul 23 19:32:26 2009
Last mount time: Sat May 29 08:46:56 2010
Last write time: Sat May 29 08:46:56 2010
Mount count: 4
Maximum mount count: 26
Last checked: Sat May 8 21:02:48 2010
Check interval: 15552000 (6 months)
Next check after: Thu Nov 4 21:02:48 2010
Lifetime writes: 1825 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 1a030567-e52e-4f1e-bc60-31a288283802
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00032ed5
Journal start: 12599


> In particular, if one used dd to copy the contents (a file system) of
> one partition to another partition, does the target partition end up
> with the same UUID or a different UUID? If you did a byte-for-byte
> copy of an entire disk to another disk of the exact same size (and
> model, but different serial number), would the UUIDs of partitions
> change or still be the same on the target disk?)
>
> (Is it similar to, or different than, the situation with filesystem
> labels (specifically, that if you copied a partition as above you'd
> end up with two partitions with the same label, and you'd have to
> change one (or otherwise deal with the non-uniqueness))?)
>
> Thanks,
> Daniel
>
>


--
Seek truth from facts.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4C2E2949.30805(a)cox.net
First  |  Prev  | 
Pages: 1 2 3
Prev: atomically concurrent writes question
Next: Using OTP tokens on Debian