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@HP-DL360 ~]# fdisk -l /dev/sda [root@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
On Sat, 25 Jun 2011, Always Learning wrote:
To: CentOS mailing list centos@centos.org From: Always Learning centos@u6.u22.net Subject: Re: [CentOS] how do determine last file system on disk?
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
Yes I second that. I prefer to use the GUI version, as you can see at a glance all you need to know about a drive's partitions.
Plus you can make a screenshot of a disk's partitions, in case you loose a disk and have to replace it, and re-partition it, like I had to earlier this year. Just follow whats on the screenshot.
Kind Regards,
Keith Roberts
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Sat, Jun 25, 2011 at 2:41 PM, Always Learning centos@u6.u22.net wrote:
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
--
Thanx, I don't have a machine with X installed at my disposal right now, only servers.
At Sat, 25 Jun 2011 13:46:01 +0200 CentOS mailing list centos@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@HP-DL360 ~]# fdisk -l /dev/sda [root@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
If '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.
On Sat, Jun 25, 2011 at 3:16 PM, Robert Heller heller@deepsoft.com wrote:
If '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.
--
All the drives are old 160GB SATA. There's 1x 160GB IDE as well.
They were used in the office on various machines, so no hardware RAID, but they definitely had some data on them. I did get some drives with software RAID on and could recover the data, but there's 2 drives which I can't figure out what filesystem they have / had on them. We use Linux & FreeBSD, so I suspect they had ZFS / UFS on them, but couldn't mount them on a FreeBSD server with ZFS or UFS either.
On 06/26/11 12:58 AM, Rudi Ahlers wrote:
All the drives are old 160GB SATA. There's 1x 160GB IDE as well.
They were used in the office on various machines, so no hardware RAID, but they definitely had some data on them. I did get some drives with software RAID on and could recover the data, but there's 2 drives which I can't figure out what filesystem they have / had on them. We use Linux & FreeBSD, so I suspect they had ZFS / UFS on them, but couldn't mount them on a FreeBSD server with ZFS or UFS either.
is it possible you used the raw disk without partitioning? so in linux, that would be /dev/sdb instead of /dev/sdb1 or whatever.
on a random server with normally partitioned disks...
# file -s /dev/sda /dev/sda: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 63, 256977 sectors; partition 2: ID=0xfd, starthead 0, startsector 257040, 4192965 sectors; partition 3: ID=0xfd, starthead 0, startsector 4450005, 138914055 sectors, code offset 0x48
# file -s /dev/sda1 /dev/sda1: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
On Sun, Jun 26, 2011 at 10:04 AM, John R Pierce pierce@hogranch.com wrote:
On 06/26/11 12:58 AM, Rudi Ahlers wrote:
All the drives are old 160GB SATA. There's 1x 160GB IDE as well.
They were used in the office on various machines, so no hardware RAID, but they definitely had some data on them. I did get some drives with software RAID on and could recover the data, but there's 2 drives which I can't figure out what filesystem they have / had on them. We use Linux & FreeBSD, so I suspect they had ZFS / UFS on them, but couldn't mount them on a FreeBSD server with ZFS or UFS either.
is it possible you used the raw disk without partitioning? so in linux, that would be /dev/sdb instead of /dev/sdb1 or whatever.
on a random server with normally partitioned disks...
# file -s /dev/sda /dev/sda: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 63, 256977 sectors; partition 2: ID=0xfd, starthead 0, startsector 257040, 4192965 sectors; partition 3: ID=0xfd, starthead 0, startsector 4450005, 138914055 sectors, code offset 0x48
# file -s /dev/sda1 /dev/sda1: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
-- john r pierce N 37, W 122 santa cruz ca mid-left coast
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
It's hard to say. They've been in the cupboard for along time and I don't know which tech did what on them, which is why I'm trying to see which file systems were on them last, so that I can see what data is on them.
On 06/26/11 1:11 AM, Rudi Ahlers wrote:
It's hard to say. They've been in the cupboard for along time and I don't know which tech did what on them, which is why I'm trying to see which file systems were on them last, so that I can see what data is on them.
well, if as you say...
[root@HP-DL360 ~]# file -s /dev/sda /dev/sda: empty
I'm guessing the tech wiped them clean. `dd if=/dev/zero of=/dev/sda bs=65536` will do that nicely.
On Sun, 26 Jun 2011, Rudi Ahlers wrote:
To: CentOS mailing list centos@centos.org From: Rudi Ahlers Rudi@SoftDux.com Subject: Re: [CentOS] how do determine last file system on disk?
On Sun, Jun 26, 2011 at 10:04 AM, John R Pierce pierce@hogranch.com wrote:
On 06/26/11 12:58 AM, Rudi Ahlers wrote:
All the drives are old 160GB SATA. There's 1x 160GB IDE as well.
They were used in the office on various machines, so no hardware RAID, but they definitely had some data on them. I did get some drives with software RAID on and could recover the data, but there's 2 drives which I can't figure out what filesystem they have / had on them. We use Linux & FreeBSD, so I suspect they had ZFS / UFS on them, but couldn't mount them on a FreeBSD server with ZFS or UFS either.
is it possible you used the raw disk without partitioning? so in linux, that would be /dev/sdb instead of /dev/sdb1 or whatever.
on a random server with normally partitioned disks...
# file -s /dev/sda /dev/sda: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 63, 256977 sectors; partition 2: ID=0xfd, starthead 0, startsector 257040, 4192965 sectors; partition 3: ID=0xfd, starthead 0, startsector 4450005, 138914055 sectors, code offset 0x48
# file -s /dev/sda1 /dev/sda1: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
-- john r pierce N 37, W 122 santa cruz ca mid-left coast
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
It's hard to say. They've been in the cupboard for along time and I don't know which tech did what on them, which is why I'm trying to see which file systems were on them last, so that I can see what data is on them.
What about using a spare low spec machine with removable EIDE and SATA drive caddies? This would come in handy for times like these, or if you needed to wipe a drive completely befroe disposal?
HTH
Keith Roberts
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Sun, Jun 26, 2011 at 10:26 AM, Keith Roberts keith@karsites.net wrote:
It's hard to say. They've been in the cupboard for along time and I don't know which tech did what on them, which is why I'm trying to see which
file
systems were on them last, so that I can see what data is on them.
What about using a spare low spec machine with removable EIDE and SATA drive caddies? This would come in handy for times like these, or if you needed to wipe a drive completely befroe disposal?
HTH
Keith Roberts
Keith, don't take this the wrong way, but you're going off the beaten track here.
Whether the drives are attached to a motherboard, or USB disk caddy doesn't change the file systems on them
On Sun, 26 Jun 2011, Rudi Ahlers wrote:
To: CentOS mailing list centos@centos.org From: Rudi Ahlers Rudi@SoftDux.com Subject: Re: [CentOS] how do determine last file system on disk?
On Sun, Jun 26, 2011 at 10:26 AM, Keith Roberts keith@karsites.net wrote:
It's hard to say. They've been in the cupboard for along time and I don't know which tech did what on them, which is why I'm trying to see which
file
systems were on them last, so that I can see what data is on them.
What about using a spare low spec machine with removable EIDE and SATA drive caddies? This would come in handy for times like these, or if you needed to wipe a drive completely befroe disposal?
HTH
Keith Roberts
Keith, don't take this the wrong way, but you're going off the beaten track here.
Whether the drives are attached to a motherboard, or USB disk caddy doesn't change the file systems on them
Absolutely. You did say they have been in a cupboard for some time, and using a spare machine with removable EIDE or SATA drive caddies would allow you to swap the EIDE or SATA drives quickly into the caddies for doing whatever you want to them, without having to fiddle about and install the drive permanently.
But as the job is almost done, I guess that's not important now?
Kind Regards,
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
At Sun, 26 Jun 2011 09:58:16 +0200 CentOS mailing list centos@centos.org wrote:
On Sat, Jun 25, 2011 at 3:16 PM, Robert Heller heller@deepsoft.com wrote:
If '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.
--
All the drives are old 160GB SATA. There's 1x 160GB IDE as well.
They were used in the office on various machines, so no hardware RAID, but they definitely had some data on them. I did get some drives with software RAID on and could recover the data, but there's 2 drives which I can't figure out what filesystem they have / had on them. We use Linux & FreeBSD, so I suspect they had ZFS / UFS on them, but couldn't mount them on a FreeBSD server with ZFS or UFS either.
Wondering: could these extra 2 drives have been 'spare' disks that were never actually installed? And got mixed in with the 'used' drives?
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...
On Sun, Jun 26, 2011 at 12:53 PM, Robert Heller heller@deepsoft.com wrote:
Wondering: could these extra 2 drives have been 'spare' disks that were never actually installed? And got mixed in with the 'used' drives?
I doubt it since there are quite a few drives that were part of a RAID set and I could get some data from them.
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...
No floor waxing or other "vibrating" machines come in this office.
So I guess the techs just completely wiped them for security or other reasons. Unfortunately none of the guys remember.
But it's fine, I'll just salvage what I can from the other drives and then resell these to someone else who can use them.
-- Robert Heller -- 978-544-6933 / heller@deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 06/26/11 3:53 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...
in that scenario, you would get nothing but servo errors from the drive, they wouldn't even finish spinning up
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 06/27/11 1:40 PM, Lamar Owen wrote:
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.
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.
If you somehow managed to magnetically bulk erase the drive it would indeed be bricked, it wouldn't pass the initial spinnup and seek calibration tests, and would simply report 'NOT READY' and/or 'FATAL ERROR'. if the magnetic erasure was partial and just weakened a small part of the disk, you'd get servo errors attempting to go anywhere near that part of the disk.
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.
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 them
Running "file -s /dev/{some_partition}" will generally tell you something.
On Sat, Jun 25, 2011 at 6:49 PM, Robert Nichols rnicholsNOSPAM@comcast.netwrote:
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
them
Running "file -s /dev/{some_partition}" will generally tell you something.
-- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
It did:
[root@HP-DL360 ~]# file -s /dev/sda /dev/sda: empty
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@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@backup670 ~]#
On a RHEL 6.1 box here: [root@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@www ~]#
Useful stuff.
On Sat, Jun 25, 2011 at 7:14 PM, Lamar Owen lowen@pari.edu wrote:
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@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@backup670 ~]#
On a RHEL 6.1 box here: [root@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@www ~]#
Useful stuff. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
wow, this is quite a neat trick!
But, it didn't help me much:
[root@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@HP-DL360 ~]# fdisk -l /dev/sda [root@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 with
On Sunday, June 26, 2011 04:00:46 AM Rudi Ahlers wrote:
[root@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@HP-DL360 ~]# fdisk -l /dev/sda [root@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 with
Ok, 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 with
The 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=...
There's quite the list.
-
Always Learning -
John R Pierce -
Keith Roberts -
Lamar Owen -
Robert Heller -
Robert Nichols -
Rudi Ahlers