Hi all, Does anyone know how to determine which file system a disk was formatted with, if fdisk -l doesn't show it? usb-storage: device found at 5 usb-storage: waiting for device to settle before scanning Vendor: Model: Rev: Type: Direct-Access ANSI SCSI revision: 02 sd 7:0:0:0: Attached scsi disk sda sd 7:0:0:0: Attached scsi generic sg0 type 0 usb-storage: device scan complete usb 1-4: USB disconnect, address 5 usb 1-4: new high speed USB device using ehci_hcd and address 6 usb 1-4: configuration #1 chosen from 1 choice scsi8 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 6 usb-storage: waiting for device to settle before scanning Vendor: Model: Rev: Type: Direct-Access ANSI SCSI revision: 02 sd 8:0:0:0: Attached scsi disk sda sd 8:0:0:0: Attached scsi generic sg0 type 0 usb-storage: device scan complete [root at HP-DL360 ~]# fdisk -l /dev/sda [root at HP-DL360 ~]# I need to see what data is on a bunch of disks that I found in storage and would prefer to first check if there's anything of use on them before I format them -- Kind Regards Rudi Ahlers SoftDux Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20110625/653d9fbb/attachment-0002.html>
> Does anyone know how to determine which file system a disk was > formatted with, if fdisk -l doesn't show it?I would use gparted from the command line or from Gnome's / Applications / System Tools menu yum install gparted -- With best regards, Paul. England, EU.
At Sat, 25 Jun 2011 13:46:01 +0200 CentOS mailing list <centos at centos.org> wrote:> > > > Hi all, > > Does anyone know how to determine which file system a disk was formatted > with, if fdisk -l doesn't show it? > > > > usb-storage: device found at 5 > usb-storage: waiting for device to settle before scanning > Vendor: Model: Rev: > Type: Direct-Access ANSI SCSI revision: 02 > sd 7:0:0:0: Attached scsi disk sda > sd 7:0:0:0: Attached scsi generic sg0 type 0 > usb-storage: device scan complete > usb 1-4: USB disconnect, address 5 > usb 1-4: new high speed USB device using ehci_hcd and address 6 > usb 1-4: configuration #1 chosen from 1 choice > scsi8 : SCSI emulation for USB Mass Storage devices > usb-storage: device found at 6 > usb-storage: waiting for device to settle before scanning > Vendor: Model: Rev: > Type: Direct-Access ANSI SCSI revision: 02 > sd 8:0:0:0: Attached scsi disk sda > sd 8:0:0:0: Attached scsi generic sg0 type 0 > usb-storage: device scan complete > [root at HP-DL360 ~]# fdisk -l /dev/sda > [root at HP-DL360 ~]# > > > > > I need to see what data is on a bunch of disks that I found in storage and > would prefer to first check if there's anything of use on them before I > format themIf 'fdisk -l /dev/sda' does not show anything, either the disks were never partitioned or formatted, at least not as a bare drive. What kind of disk is this (I know it says USB above, but I am assuming these are bare disk(s) that you installed in a USB enclosure). It is *possible* these disks were part of a *hardware* RAID array, in which case only the hardware RAID would know how to deal with them (they would have some vendor-specific metadata / superblock on them somewhere). If the disks are not partitularly large (< 1TB) if they were actually in use they would likely have a MS-DOS partition table (which fdisk -l would be displaying). If they are larger disks they might have gpt partition table (parted would show this). It is possible that they have a Solaris disk label (if they were in a Solaris machine). It is *possible* that someone used them as part of a Linux software RAID array using the whole disk, in which case there might be a MD superblock on them (mdadm might see it) and it is ALSO possible that they were part of a LVM volume group, also using the whole disk as a PV, in which case there should be LVM metadata on them (lvm might see this). If none of the above, they are just 'factory fresh', never used disks. -- Robert Heller -- 978-544-6933 / heller at deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
On 06/25/2011 06:46 AM, Rudi Ahlers wrote:> Hi all, > > Does anyone know how to determine which file system a disk was formatted with, > if fdisk -l doesn't show it?[snip]> I need to see what data is on a bunch of disks that I found in storage and would > prefer to first check if there's anything of use on them before I format themRunning "file -s /dev/{some_partition}" will generally tell you something. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
On Saturday, June 25, 2011 07:46:01 AM Rudi Ahlers wrote:> Does anyone know how to determine which file system a disk was formatted > with, if fdisk -l doesn't show it?blkid -s TYPE On a C5 box here: [root at backup670 ~]# blkid -s TYPE /dev/mapper/vg_backup670-lv_root: TYPE="ext3" /dev/md1: TYPE="swap" /dev/md0: TYPE="ext3" /dev/sdb2: TYPE="swap" /dev/sdb1: TYPE="ext3" /dev/sda2: TYPE="swap" /dev/sda1: TYPE="ext3" /dev/hda: TYPE="iso9660" /dev/vg_backup670/lv_root: TYPE="ext3" /dev/mapper/pachy--mirror-home: TYPE="xfs" /dev/vg_opt/lv_pachy: TYPE="ext4" /dev/pachy-mirror/home: TYPE="xfs" /dev/mapper/vg_opt-lv_pachy: TYPE="ext4" [root at backup670 ~]# On a RHEL 6.1 box here: [root at www ~]# blkid -s TYPE /dev/sdd1: TYPE="LVM2_member" /dev/sde1: TYPE="LVM2_member" /dev/sdk1: TYPE="LVM2_member" /dev/sdn1: TYPE="xfs" /dev/sdg1: TYPE="ext4" /dev/sds1: TYPE="LVM2_member" /dev/sdy1: TYPE="LVM2_member" /dev/sdaa1: TYPE="ext4" /dev/sdag1: TYPE="linux_raid_member" /dev/sdx1: TYPE="LVM2_member" /dev/sdaf1: TYPE="linux_raid_member" /dev/sdad1: TYPE="ext3" /dev/sdah1: TYPE="ext4" /dev/sdah2: TYPE="LVM2_member" /dev/mapper/vg_www-lv_root: TYPE="ext4" /dev/mapper/vg_www-lv_swap: TYPE="swap" /dev/md127: TYPE="ext3" /dev/mapper/vg_bak2-lv_lobak: TYPE="ext4" [root at www ~]# Useful stuff.
On Sunday, June 26, 2011 04:00:46 AM Rudi Ahlers wrote:> [root at HP-DL360 ~]# blkid -s TYPE > /dev/mapper/LVM-swap: TYPE="swap" > /dev/mapper/LVM-root: TYPE="ext3" > /dev/cciss/c0d0p1: TYPE="ext3" > /dev/LVM/root: TYPE="ext3" > /dev/LVM/swap: TYPE="swap" > /dev/mapper/LVM-data: TYPE="ext3" > [root at HP-DL360 ~]# fdisk -l /dev/sda > [root at HP-DL360 ~]#> Which filesystems can this command recognize? I checked the MAN page, but > couldn't find a list of filesystems that it's familiar withOk, you have an LVM setup, and it appears to be on a hardware RAID. Issue in turn: pvscan vgscan lvscan to see how things are sliced. They're likely all on a /dev/cciss/c0d0pX where X is the partition. That is, you have an array, and that array doesn't expose its disks in the normal /dev/sdX fashion, apparently. I guess that from seeing /dev/cciss/c0d0p1 (controller 0, disk 0, partition 1, perhaps?) which is likely mounted as /boot.
On Sunday, June 26, 2011 04:00:46 AM Rudi Ahlers wrote:> Which filesystems can this command recognize? I checked the MAN page, but > couldn't find a list of filesystems that it's familiar withThe list is found only in the source code as far as I could find; see in the e2fsprogs source tarball the files lib/blkid/probe.h and lib/blkid/probe.c The current git for probe.h is: http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=lib/blkid/probe.h;h=37e80effb4545c946d6b666ad05b195147b2fb6f;hb=HEAD There's quite the list.
On Sunday, June 26, 2011 06:53:48 AM Robert Heller wrote:> It is also possible that the drives got 'wiped' somehow, eg they were > on the bottom shelf when the cleaning crew came by with the floor waxing > machine...That would wipe more than the data; it would also wipe the embedded servo information and render the drive completely useless until someone with a servowriter for that drive rescues them..... and even then, since many drives load portions of their firmware from the disk surfaces (from reserved tracks that cannot normally be overwritten), the drive may be bricked.
On Monday, June 27, 2011 04:52:52 PM John R Pierce wrote:> On 06/27/11 1:40 PM, Lamar Owen wrote: > > That would wipe more than the data; it would also wipe the embedded servo information and render the drive completely useless until someone with a servowriter ... > I might be wrong about this, but I was led to believe that the servo > data is written with special heads onto the platters before the disks > are even assembled.Servo can be written after assembly, through a 'window' in the side of the drive that is later covered with a 'warranty void if removed' sticker. But, as you say, it is done with special heads, on a servowriter. These are highly specialized and expensive machines, and require absolute positioner accuracy better than the track spacing of the disk (a laser interferometer is one way to do this good of positioning accuracy; we use a HeNe laser interferometer on our photographic plate microdensitometer system here, and it's good to one-tenth of a wavelength of HeNe light (63 or so nanometers)). Writing servo on the individual platters, and then maintaining tolerance during platter stack assembly, would be very tricky indeed. Much easier to write servo on an assembled platter stack, to make sure the cylinders really are concentric.