Browse openbeosstorage: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date
[openbeosstorage] Re: ISO9660/cdrom progress

From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
To: openbeosstorage@xxxxxxxxxxxxx
Date: Wed, 19 Feb 2003 15:44:59 CET (+0100)
> > > that leads up to each leaf session, but once we know that, I 
> > > doubt
> > > it's=3D20
> > > much more (if any) work to know the whole tree.=3D20
> > > 
> > > For Tracker then, we could maybe have something along the lines 
> > > of 
> > > a=3D
> > > 20
> > > "session chooser" item in pop up menus for volumes existing on=
> > > 3D20
> > > multi-session media that opens up a window showing the session=
> > > 3D20
> > > inheritance tree, allowing you to mount and unmount sessions at 
> > > will.
> > > I=3D20
> > > think that sort of interface would make CD backups a lot more 
> > > useful=3D
> > > 20
> > > (providing an easily accessible, almost CVS-like backup history).
> > 
> > Yes, it probably makes the session chooser a lot more useful this
> > way... but how would you provide that feature=3F Have a parent 
> > session
> > field somewhere, and flag the sessions which doesn't have any 
> > children
> > (since they are the main sessions)=3F
> 
> Yes, something like that. But it's not looking good wrt figuring out 
> the complete inheritance hierarchy...

And in fact it would be no tree, but a DAG anyway, since a volume can 
refer to files from more than one former volume.

> On 2003-02-17 at 13:14:22 [-0800], Ingo Weinhold wrote:
[...]
> > I believe, a volume resides on a (probably virtual) partition, not
> > sharing it with other volumes.
> > 
> > * A volume set is set of volumes with the same volume set 
> > identifier 
> > (a
> > string, BTW). Each volume of the set has an individual sequence 
> > number
> > (an integer).
> 
> This is the theory, at least. In practice, it doesn't appear to be 
> used 
> in a useful way. With Nero at least, the volume set id may be set 
> arbitrarily by the user, and the sequence # appears to always be 1...

Yes.

[...]
> + Any volume on a CD can potentially reference data in any other 
> volume 
> on the same CD, regardless of session boundaries, due to the use of 
> absolute addresses (that last bit I haven't verified, but I do know 
> that files that aren't changed inbetween inherited sessions aren't 
> rewritten, based on session sizes).

I'm not so sure about the absolute addresses. They usually use the term 
`logical block number' (I haven't checked all structures, but I believe 
they do) and, as introduced in 6.2.2, they identify the blocks in the 
volumes space, i.e. on the volume (numbering starting with 0).

That files from other volumes can be `reused' is true, nevertheless. A 
directory record (cf. 9.1) has a `Volume Sequence Number' field 
identifying the volume on which the extend (== file contents) resides.

> + Volume Set IDs are used as a convenience for users only, and have 
> no 
> intrinsic meaning.

If you mean the ID itself, I think, you're right. Their usage does have 
a meaning though, as it specifies, which volumes belong to the volume 
set.

> + Virtually no one ever records more than one volume at once, so each 
> volume gets put in its own "track" in its own "session" on the CD. 
> The 
> only exceptions I've seen are the R5 CD, with three volumes in a 
> single 
> "session", each in its own "track", and Video CDs, whic are a data 
> "session" containing a single iso volume in one data "track" (with, 
> I'm 
> assuming, some sort of supplementart descriptor flagging the session 
> as 
> a Video CD) followed by an individual data "track" for eack video 
> file 
> containing the raw MPEG data (and incidentally, the iso has directory 
> entries for the video files that refer to the data stored in the 
> video 
> tracks). 
> 
> What I think this means for us is that (barring further discoveries) 
> we 
> can't completely know which volumes form a set without parsing the 
> whole filesystem to look for references to othjer sessions, and even 
> that fails in the event that all the files in the volume are updated.

I disagree. Unless you indeed have an sample CD which violates the 
standard, but works on Windows (and other OSs). Which volumes belong to 
a volume set is clearly defined by the standard -- those having the 
same volumes set ID -- and recognizing that requires nothing more than 
reading the primary volume descriptors. In practice, this may turn out 
to be a bit difficult to do with our current disk_scanner architecture.

Regarding which volume reuses data from which former ones, you're 
right. Potentially this could be all in the volume set, but actually I 
don't find that information of much interest, anyway. Interesting are 
the volume groups IMHO.

> > Axel wrote:
> > > Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > > > > What
> > > > > about the chronological order of the volumes on disk -- is it
> > > > > implied
> > > > > (by the order of appearance) or explicit (time stamp)=3F
> > > > Not sure. Possibly both.
> > > 
> > > No, I don't think it's that - I dunno if anyone knows Nero, but 
> > > there
> > > you can actually choose the session to use in a nice tree.
> > > So you could do things like:
> > > 1. session
> > > 2. session based on 1. session
> > > 3. session based on 2. session
> > > 4. session based on 2. session
> > > 
> > > Then you should (IMO) give the users the choice between session 3 
> > > &
> > > 4,
> > > since they are the latest sessions in their set.
> > 
> > If I interpret, what I read, correctly, a volume can't explicitly 
> > refer
> > to another. They can be in the same volume set at most.
> 
> Yes. I think they do, though. I think that standard is only partially 
> used or incorrect or obsolete.

I haven't heard of any standard replacing ISO9660 yet, but that doesn't 
mean much. ;-)

> > About session/
> > tracks/... I don't know, since those are not covered by the ISO9660
> > standard (Tyler?). 
> 
> A cd is composed of sessions, and sessions are composed of tracks. 
> Usually data sessions contain data tracks, and audio sessions contain 
> audio tracks, but it's not technmically required. The way I'm 
> handling 
> thing currently, each track in a data session ends up being a 
> disk_scanner session, while the entirety of an audio session (with 
> all 
> its tracks) is treated as a disk_scanner session. 

Sounds reasonable.

> > I wonder, if, what Nero presents, is deduced knowledge. By 
> > analyzing
> > the directory hierarchy of a volume (group) it is certainly 
> > possible 
> > to
> > find out, on which volumes the referred-to files are located.
> 
> I believe Nero just shows the physical layout of the disc.  At least, 
> I 
> haven't been able to get it to show an inheritance hierarchy.

So, Axel has seen trees where there weren't any? Oh, oh,... ;-)

> > A far as I understand the matter, the on-disk structures don't span 
> > a
> > tree. I see, that there is a list of volume groups per volume set 
> > (or 
> > a
> > list of volume subset, if you want), and that presenting the latest
> > group of each volume set to the user would be the default behavior 
> > I
> > can imagine (perhaps with an option to switch to older groups). For 
> > the
> > volumes are at FS level, I think the extended_partition_info and
> > BPartition structure (not session_info/BSession) would need to be
> > extended.
> 
> As far as I can tell, they can span a tree, but in practice they 
> seldom 
> do (it does appears that the standard dictates this is not possible, 
> but I've made discs in Nero that do this).  

Let me see, if we actually agree, but just think of different levels:

* The organization level is defined explicitely by the standard: There 
are volume sets, which consist of volume sequences, which are 
factorized by creation time into sequences of volume groups. Each 
volume group can reuse any data of the former ones. No trees here.

* A second structural level is implied by the reusage of files from 
other volumes in a volume. Since files from any volume from the volume 
set can be referred, this structure is in general a DAG. E.g. in Axel's 
example one could add a 5th session reusing files from sessions 3 and 4 
(given that those sessions mean volumes).

> It seems to me, that the overwhelmingly common case for session 
> inheritance is the case in which a single volume is repeatedly 
> updated 
> using the same volume name.  Thus, somewhat similarily to what you 
> suggest above, perhaps Tracker should present by default only the 
> lastest volume (by date) out of any set of volumes on a given CD with 
> identical volume names, and then present some way to switch to any of 
> the earlier volumes, if so desired.  And since this is a file system 
> dependent feature, perhaps we should add a flag to 
> extended_partition_info to indicate when this sort of multivolume 
> behavior should be used (I guess we'd need to add a date as well). 
> Thoughts?

For the DiskDevice API I could imagine to add two methods, BPartition *
Supersedes() and BPartition *SupersededBy() to BPartition. Relating 
this to the terminology of the standard, this reflects the list of 
volume groups. The Tracker would simply present the tail of the list as 
default and the others as options (e.g. an entry in the mount menu 
could have a submenu listing all options).

Regarding the extended_partition_info structure I think it could be 
extended by two fields specifying the session and partition index of 
the superseded partition (-1 for `normal' partitions). I would try to 
avoid adding too many specifics of this particular standard. A time 
field wouldn't harm, but we would also need another field with the 
volume set identifier, which doesn't fit very well, I feel.

The interface for the disk_scanner modules would need to be adjusted in 
any case. I will think about this.

CU, Ingo
Follow-Ups:

[openbeosstorage] Re: ISO9660/cdrom progress
From: Axel =?iso-8859-1?q?D=F6rfler

[openbeosstorage] Re: ISO9660/cdrom progress
From: Tyler Dauwalder
[openbeosstorage] Re: ISO9660/cdrom progress

Other related posts:
