Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
In article <[EMAIL PROTECTED]> you wrote: > The real problem is that our disks usually do not have a volume label. > Outside of all file systems. > The "signatures" that we rely on today are located in different places, > so that a filesystem can have several valid signatures at the same time. > And we first know where to look when we know the type already. > > Design a Linux partition table format, where a partition descriptor > has fields start, end, fstype, fslabel, and the whole disk has a vollabel. > Put it in sector 0-N for an all-Linux disk, and in sectors pointed at > by a classical DOS-type partition table entry when the disk is shared. I don't understand that. Do you propose something like *BSD or Solaris disklabels? In that case a whole new set of user utilities would be needed to create your new tables as well as maintaining the old style partition tables. The process of copying or moving fs around disks seems to be quite common as tools like partition magic or parted suggest. Your idea would make that process more difficult and less user-friendly. It should imho always be simple to backup an fs to tape from a dying disk and restore it to a new one without losing the label etc. Perhaps putting this kind of information into a generalized start sector for all Linux fs would be a better idea (is that what you meant?). Copying an fs would again be as easy as using dd or cp. Of course this means that most Linux fs types including swap partitions should leave this start sector alone. A common mkfs would create that leading block after the mkfs. successfully created the fs meta-contents. It would be optimal imho if the partition table entry contains the start sector and size only, and all other information like type, uuid, label etc. is within the fs disk space. No out-of-band fs information anymore. The disk volume label should be located outside all fs as you mentioned but separated from the actual fs labels. -- Michail Brzitwa <[EMAIL PROTECTED]>+49-511-343215 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
In article [EMAIL PROTECTED] you wrote: The real problem is that our disks usually do not have a volume label. Outside of all file systems. The "signatures" that we rely on today are located in different places, so that a filesystem can have several valid signatures at the same time. And we first know where to look when we know the type already. Design a Linux partition table format, where a partition descriptor has fields start, end, fstype, fslabel, and the whole disk has a vollabel. Put it in sector 0-N for an all-Linux disk, and in sectors pointed at by a classical DOS-type partition table entry when the disk is shared. I don't understand that. Do you propose something like *BSD or Solaris disklabels? In that case a whole new set of user utilities would be needed to create your new tables as well as maintaining the old style partition tables. The process of copying or moving fs around disks seems to be quite common as tools like partition magic or parted suggest. Your idea would make that process more difficult and less user-friendly. It should imho always be simple to backup an fs to tape from a dying disk and restore it to a new one without losing the label etc. Perhaps putting this kind of information into a generalized start sector for all Linux fs would be a better idea (is that what you meant?). Copying an fs would again be as easy as using dd or cp. Of course this means that most Linux fs types including swap partitions should leave this start sector alone. A common mkfs would create that leading block after the mkfs.fs type successfully created the fs meta-contents. It would be optimal imho if the partition table entry contains the start sector and size only, and all other information like type, uuid, label etc. is within the fs disk space. No out-of-band fs information anymore. The disk volume label should be located outside all fs as you mentioned but separated from the actual fs labels. -- Michail Brzitwa [EMAIL PROTECTED]+49-511-343215 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test12 & raid0 -> fs corruption?
Using plain test12, an ide raid0 configuration and raidtools 0.90 I found that within at most one hour of normal work my /dev/md0 (ext2) suffered from the same sort of corruption mentioned here for some test12-pre versions. The setup: two IBM ide disks (UDMA 100) connected to a Promise PDC20265 on an Asus A7V. Both disks contained the same partitioning: one swap (same priority on both disks) and one autoraid partition, mkraid'ed to a raid0 /dev/md0. The ide disk accesses itself were ok, I ran several bonnie -s 500 before copying real data, moreover there were no swap errors at any time (bonnies block read speed reached 70MB/s btw). After moving my whole /usr and /home dirs to md0, rebooting and doing some editing and compiling I suddenly noticed my .viminfo and .newsrc containing small parts of a mail folder file (not sure how much but <= 4k anyway). Several files in /var/log were corrupted as well. The mail folder file in question hasn't been accessed since the last reboot so parts of it shouldn't have been in the buffer cache. After a reboot and another half an hour or so the same sort of file corruption happened again, this time binary data. On both occasions there were no kernel complaints, both times an fsck of /dev/md0 found no errors. I then deleted md0 and put /usr into one former autoraid partitions and /home into the other. No corruption since then. I can provide more information if necessary. -- Michail Brzitwa <[EMAIL PROTECTED]>+49-511-343215 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test12 raid0 - fs corruption?
Using plain test12, an ide raid0 configuration and raidtools 0.90 I found that within at most one hour of normal work my /dev/md0 (ext2) suffered from the same sort of corruption mentioned here for some test12-pre versions. The setup: two IBM ide disks (UDMA 100) connected to a Promise PDC20265 on an Asus A7V. Both disks contained the same partitioning: one swap (same priority on both disks) and one autoraid partition, mkraid'ed to a raid0 /dev/md0. The ide disk accesses itself were ok, I ran several bonnie -s 500 before copying real data, moreover there were no swap errors at any time (bonnies block read speed reached 70MB/s btw). After moving my whole /usr and /home dirs to md0, rebooting and doing some editing and compiling I suddenly noticed my .viminfo and .newsrc containing small parts of a mail folder file (not sure how much but = 4k anyway). Several files in /var/log were corrupted as well. The mail folder file in question hasn't been accessed since the last reboot so parts of it shouldn't have been in the buffer cache. After a reboot and another half an hour or so the same sort of file corruption happened again, this time binary data. On both occasions there were no kernel complaints, both times an fsck of /dev/md0 found no errors. I then deleted md0 and put /usr into one former autoraid partitions and /home into the other. No corruption since then. I can provide more information if necessary. -- Michail Brzitwa [EMAIL PROTECTED]+49-511-343215 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
