Prev: how does user application call NAPI poll method of network device driver.
Next: firefox and google maps
From: Rahul on 20 Feb 2010 21:39 Robert Riches <spamtrap42(a)verizon.net> wrote in news:slrnho11u4.i5f.spamtrap42(a)one.localnet: > If that were done, other than the difference between a symlink > being a path in text form and this new thing being a UUID and > inode number (at least partly in text form), what practical > differences would there be from a symlink? One big difference. Hardlinks are symmetric. THe data itself doesn't get deleted till the last surviving hard link exists. With symlinks OTOH if the primary file is gone the link's broken. -- Rahul
From: Rahul on 20 Feb 2010 21:40 Florian Diesch <diesch(a)spamfence.net> wrote in news:rnf657-c3q.ln1 @mid.florian-diesch.de: > But it would make all files on file system inaccessible if I change the > file system's UUID. And I'll be really in trouble if I have two file True. But an equivalent danger is always present with symlinks. If you unmount a FS all symlinks are inaccessible. -- Rahul
From: Rahul on 20 Feb 2010 21:44 unruh <unruh(a)wormhole.physics.ubc.ca> wrote in news:slrnho147c.604.unruh(a)wormhole.physics.ubc.ca: > I can change the uuid of a partition at any time I want. I can give the > same uuid to anther partition. I can unmount the partition with that > uuid. Yes, if you want to mess up you always can. :) >FOr inodes, they change when you reformat. But when you refomat > you get a waring that all data will be lost. DO you really want all data > on all disks to be lost if you replace one disk? Why would data on "all" disks be lost? Only cross-FS links would dangle. That's all. If you did not use cross-FS links even with the new system you wouldn't see any change at all. > inode numbers are hard-- they are permanantly assigned and if they are > lost so is all the data. uuids are soft, they can change. If you made > them hard as well, any change would loose you all your data. inode numbers would stay "hard" even in the new arrangement. On both filesystems. Only the cross-FS links would utilize the new "soft" tuples. -- Rahul
From: Robert Heller on 20 Feb 2010 22:12 At Sat, 20 Feb 2010 22:04:47 +0000 (UTC) Rahul <nospam(a)invalid.invalid> wrote: > > The Natural Philosopher <tnp(a)invalid.invalid> wrote in news:hlpfid$b1j$3 > @news.albasani.net: > > > There is a structural reason. > > > > Hard links are duplicate directory entries actually on the disk. > > > > They cannot refer to another disk. > > > > Thanks for the explanations guys. I think I understand how it is done. Buy > nothing in these explainations precludes why the links cannot point to a > inode on another filesystem that is also mounted. If two filessytems are > both mounted all storage on them is pretty much identical in terms of > inodes etc. , right? Or maybe I don't see the obvious.... No, inodes are file system specific. Each file system is its own self contained data struture. Each mount point has a kernel data struture that points to things like the FS module (eg ext2.ko, ext3.ko, vfat.ko, hffs.ko, xfs.ko, ntfs.ko, whatever), and info as to the 'physiical' device (/dev/hda1 /dev/sda4, etc.), and mount point (/, /boot, /media/usbstick, etc.). > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: despen on 20 Feb 2010 22:15
Rahul <nospam(a)nospam.invalid> writes: > Robert Riches <spamtrap42(a)verizon.net> wrote in > news:slrnho11u4.i5f.spamtrap42(a)one.localnet: > >> If that were done, other than the difference between a symlink >> being a path in text form and this new thing being a UUID and >> inode number (at least partly in text form), what practical >> differences would there be from a symlink? > > One big difference. Hardlinks are symmetric. THe data itself doesn't get > deleted till the last surviving hard link exists. > > With symlinks OTOH if the primary file is gone the link's broken. Soft links are not broken when the file is gone. They are working exactly as designed. There is no requirement that the target of a soft link exist. Try this command: cd /tmp ln -s linktonowhere nowhere We have hard links for one purpose and soft links for another. |