|
From: Florian K. <fl...@ei...> - 2014-11-17 17:57:22
|
Greetings: When considering whether two SkFile segments can be merged (in maybe_merge_nsegments), the segment name is not taken into consideration. I'm wondering whether it should be. Segment names are, in general, user-visible via the following chain: VG_(get_am_filename) <-- VG_(get_objname) <-- VG_(describe_IP) That could lead to an incorrect segment name being reported for a given address: Suppose an address X which is (originally) inside a segment named FOO. Should FOO get merged into a segment named BAR then VG_(am_get_filename)(X) would return BAR which is wrong (and maybe confusing). Or does equality of the "dev" and "ino" fields imply equality of the segment names? If so, checking the name would of course be redundant. Florian |
|
From: Julian S. <js...@ac...> - 2014-11-18 09:16:33
|
On 11/17/2014 06:57 PM, Florian Krohm wrote: > Or does equality of the "dev" and "ino" fields imply equality of the > segment names? If so, checking the name would of course be redundant. I believe (#include <disclaimer.h> etc) that the dev:ino fields uniquely identify a file and so, as you say, their equality implies equality of the file's name. J |
|
From: Tom H. <to...@co...> - 2014-11-18 09:45:20
|
On 18/11/14 09:16, Julian Seward wrote: > On 11/17/2014 06:57 PM, Florian Krohm wrote: > >> Or does equality of the "dev" and "ino" fields imply equality of the >> segment names? If so, checking the name would of course be redundant. > > I believe (#include <disclaimer.h> etc) that the dev:ino fields uniquely > identify a file and so, as you say, their equality implies equality of > the file's name. They do identify a file yes (I have a nagging feeling that there is an issue here with one of the newer filesystems but can't find anything to back that up on google) but they don't actually imply equality of name because hard links allow a file to have more than one name ;-) I think just comparing dev:ino is fine here. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2014-11-18 10:02:37
|
On 18/11/14 09:45, Tom Hughes wrote: > They do identify a file yes (I have a nagging feeling that there is an > issue here with one of the newer filesystems but can't find anything to > back that up on google) but they don't actually imply equality of name > because hard links allow a file to have more than one name ;-) More googling seems to say that there certainly was an issue with btrfs at one point where inodes are only unique within a subvolume but multiple subvolumes would have the same device ID. What I haven't managed to figure out is whether that was ever changed. See, for example: http://www.spinics.net/lists/linux-btrfs/msg07302.html https://www.mail-archive.com/lin...@vg.../msg20877.html Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Florian K. <fl...@ei...> - 2014-11-18 10:15:41
|
On 18.11.2014 11:02, Tom Hughes wrote:
> On 18/11/14 09:45, Tom Hughes wrote:
>
>> They do identify a file yes (I have a nagging feeling that there is an
>> issue here with one of the newer filesystems but can't find anything to
>> back that up on google) but they don't actually imply equality of name
>> because hard links allow a file to have more than one name ;-)
>
> More googling seems to say that there certainly was an issue with btrfs
> at one point where inodes are only unique within a subvolume but
> multiple subvolumes would have the same device ID.
So perhaps we should just err on the safe side and include testing
segment names for equality? It's not that this is on some critical path
or so. And we'd be comparing indices into a string table anyhow.
Florian
|
|
From: Julian S. <js...@ac...> - 2014-11-18 20:35:40
|
>>> They do identify a file yes (I have a nagging feeling that there is an >>> issue here with one of the newer filesystems but can't find anything to >>> back that up on google) but they don't actually imply equality of name >>> because hard links allow a file to have more than one name ;-) Ah yes. > So perhaps we should just err on the safe side and include testing > segment names for equality? It's not that this is on some critical path > or so. And we'd be comparing indices into a string table anyhow. In view of Tom's observation, that might not be safe thing to do. The aspacemgr tries to merge segments as much as it can, and I suspect there are places that assume "maximal merging" has been done. If we wind up with two adjacent segments which could be merged except for the fact that the names are different, even though the dev/ino numbers are the same, something might break. That said I think it's a pretty unlikely scenario. We'd need to have a file with two different names (already rare) and two mappings of it which are adjacent both in address space and in offset in the file, but using the two different names. J |