[linux-lvm] About fstab and fsck

[linux-lvm] About fstab and fsck

[Madan Thapa]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

Hi,

I recently added a new disk ( secondary 750G) and added it into a VG  and
then increased the size of the LV.


[root@server ~]# pvdisplay | egrep 'PV Name|PV Size|VG Name'
  PV Name               /dev/sda2
  VG Name               VolGroup00
  PV Size               698.54 GB / not usable 4.40 MB
  PV Name               /dev/sdb1
  VG Name               VolGroup00
  PV Size               698.64 GB / not usable 10.34 MB



[root@server ~]# lvdisplay | egrep 'LV Name|LV Size|VG Name'
  LV Name                /dev/VolGroup00/LogVol00
  VG Name                VolGroup00
  LV Size                1.32 TB
  LV Name                /dev/VolGroup00/LogVol01
  VG Name                VolGroup00
  LV Size                1.94 GB
[root@server ~]#



======================


Can you please advise of the following q:

1) Do we need to change anything in  /etc/fstab or the second disk will be
automatically mounted on reboot?

current fstab is
###############
[root@server ~]# cat /etc/fstab
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
[root@server ~]#



2)  For 1.3 TB , fsck is going to take a long time

Is it good idea disable fsck completely on reboot and or  do scheduled
manual fsck.  Due to the nature of data , even manual fsck is not preffered
though, but with tight budget, other things are not possible

[-- Attachment #2: Type: text/html, Size: 4492 bytes --]

Re: [linux-lvm] About fstab and fsck

[David Robinson]

> I recently added a new disk ( secondary 750G) and added it into a VG  and
> then increased the size of the LV.
>
> Can you please advise of the following q:
>
> 1) Do we need to change anything in  /etc/fstab or the second disk will be
> automatically mounted on reboot?

You said you increased the size of a LV, not added a new LV. If you
added a new LV and created a filesystem on it you'd want to add it to
fstab, but if you're growing an existing LV and filesystem you
wouldn't need to change anything - the filesystem you grew would
already be listed in fstab. You did grow the filesystem too, right?
Why do you think you need to reboot?

> 2)  For 1.3 TB , fsck is going to take a long time
>
> Is it good idea disable fsck completely on reboot and or  do scheduled
> manual fsck.  Due to the nature of data , even manual fsck is not preffered
> though, but with tight budget, other things are not possible

Usually you'd want to have fsck enabled for your root filesystem, but
by the looks of it the LV and filesystem you grew _is_ your root
filesystem... so considering its size, I'd turn it off. Hopefully the
"fsck takes _forever_" problem will die when btrfs becomes the
standard filesystem.

--Dave

Re: [linux-lvm] About fstab and fsck

[Chris Cox]

On Wed, 2009-02-11 at 21:58 +0000, David Robinson wrote:
...
> Usually you'd want to have fsck enabled for your root filesystem, but
> by the looks of it the LV and filesystem you grew _is_ your root
> filesystem... so considering its size, I'd turn it off. Hopefully the
> "fsck takes _forever_" problem will die when btrfs becomes the
> standard filesystem.

I'm not aware of any feature in btrfs that will prevent
the fsck time issue on very large fs's.

Until something fairly radical happens in fs design, I'd avoid
very large fs's.

But if you know differently about btrfs... please share.

Re: [linux-lvm] About fstab and fsck

[Madan Thapa]

[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]

You said you increased the size of a LV, not added a new LV. If you
added a new LV and created a filesystem on it you'd want to add it to
fstab, but if you're growing an existing LV and filesystem you
wouldn't need to change anything - the filesystem you grew would
already be listed in fstab. You did grow the filesystem too, right?
Why do you think you need to reboot?

-------------->

A new disk was added /dev/sdb , to grow existing LV on /dev/sda. So yes, no
need to change anything in fstab


[root@server ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               VolGroup00
  PV Size               698.54 GB / not usable 4.40 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              22353
  Free PE               0
  Allocated PE          22353
  PV UUID               L6igzx-qX3V-TEpR-0A6b-DXT9-eIf9-6Kl65Q

  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               VolGroup00
  PV Size               698.64 GB / not usable 10.34 MB
  Allocatable           yes
  PE Size (KByte)       32768
  Total PE              22356
  Free PE               1556
  Allocated PE          20800
  PV UUID               7tN9mF-ZUGA-Fsdx-SU30-OHBL-gcVf-IYiDDK

[root@server ~]#



[root@server ~]# cat /etc/fstab
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
[root@server ~]#



[root@server ~]# fdisk -l

Disk /dev/sda: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14       91201   732467610   8e  Linux LVM

Disk /dev/sdb: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       91201   732572001   83  Linux
[root@server ~]#

( strange though ,  ID is still showing 83 for /dev/sdb1 , even when i used
8e , while formatting /dev/sdb, ) ,  i selected 83 for t during fdisk for
/dev/sdb

current status
------------------------
[root@server ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      1.3T  426G  812G  35% /
/dev/sda1              99M   29M   65M  31% /boot
tmpfs                 3.9G     0  3.9G   0% /dev/shm
[root@server ~]#



old status
---------------------

[root@server ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      730  670G  60G  35% /
/dev/sda1              99M   29M   65M  31% /boot
tmpfs                 3.9G     0  3.9G   0% /dev/shm
[root@server ~]#




why reboot? - > I do not intend to do so, just wanted to know.


I agree with chris (using not too large disk) ,  we do use only 250G disks (
max size) for most of our servers ( except some CDP servers),  but in this
case someone else wanted little help,  and was bent on using large disk, I
did caution him though


Thanks

[-- Attachment #2: Type: text/html, Size: 7952 bytes --]

Re: [linux-lvm] About fstab and fsck

[Madan Thapa]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Btw,

please disregard the old status:

old status
---------------------

[root@server ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      730  670G  60G  35% /
/dev/sda1              99M   29M   65M  31% /boot
tmpfs                 3.9G     0  3.9G   0% /dev/shm
[root@server ~]#


thats of some other server, copied  by mistake :(

[-- Attachment #2: Type: text/html, Size: 908 bytes --]

Re: [linux-lvm] About fstab and fsck

[David Robinson]

On Wed, Feb 11, 2009 at 10:03 PM, Chris Cox <chris_cox@stercomm.com> wrote:
> On Wed, 2009-02-11 at 21:58 +0000, David Robinson wrote:
> ...
>> Usually you'd want to have fsck enabled for your root filesystem, but
>> by the looks of it the LV and filesystem you grew _is_ your root
>> filesystem... so considering its size, I'd turn it off. Hopefully the
>> "fsck takes _forever_" problem will die when btrfs becomes the
>> standard filesystem.
>
> I'm not aware of any feature in btrfs that will prevent
> the fsck time issue on very large fs's.
>
> Until something fairly radical happens in fs design, I'd avoid
> very large fs's.

btrfs isn't a radically different design? Perhaps I should have
rephrased what I said - rather than btrfs being quicker at checking
and repairing the filesystem (ala fsck) it (in theory) prevents you
from ever needing to fsck in the first place. It basically trusts
nothing and checksums everything. A quick look at the features page
[1] lists:

- Checksums on data and metadata (multiple algorithms available)
- Online filesystem check
- Very fast offline filesystem check

[1] http://btrfs.wiki.kernel.org/index.php/Main_Page

--Dave

Re: [linux-lvm] About fstab and fsck

[Martin Schröder]

2009/2/11 David Robinson <zxvdr.au@gmail.com>:
> filesystem... so considering its size, I'd turn it off. Hopefully the
> "fsck takes _forever_" problem will die when btrfs becomes the
> standard filesystem.

Just a reminder: Linux has xfs since 2002. A full-blown fsck on xfs is
a rare thing.

Best
   Martin

[linux-lvm] Re: About fstab and fsck

[Stefan Monnier]

>> filesystem... so considering its size, I'd turn it off. Hopefully the
>> "fsck takes _forever_" problem will die when btrfs becomes the
>> standard filesystem.

> Just a reminder: Linux has xfs since 2002. A full-blown fsck on xfs is
> a rare thing.

Similarly, I don't know of any case where fsck on an ext3 partition
turned out to be useful.  As a matter of fact, my home router's ext3
partition is never fsck'd (it would take way too much time to this poor
266MHz thingy to fsck my 1TB filesystem).


        Stefan

Re: [linux-lvm] Re: About fstab and fsck

[Bryn M. Reeves]

Stefan Monnier wrote:
>>> filesystem... so considering its size, I'd turn it off. Hopefully the
>>> "fsck takes _forever_" problem will die when btrfs becomes the
>>> standard filesystem.
> 
>> Just a reminder: Linux has xfs since 2002. A full-blown fsck on xfs is
>> a rare thing.
> 
> Similarly, I don't know of any case where fsck on an ext3 partition
> turned out to be useful.  As a matter of fact, my home router's ext3

I wouldn't go that far. It all depends what messed the file system up 
in the first place. Ext3 bugs, minor scribbling and suchlike generally 
get tidied up reasonably well by e2fsck. It's quite true that with 
major corruption to the file system there's often not an awful lot 
left afterwards but that's true of many other file systems as well.

> partition is never fsck'd (it would take way too much time to this poor
> 266MHz thingy to fsck my 1TB filesystem).

/me wonders why a router needs a 1TB fs :-)

Bryn.

[linux-lvm] Re: About fstab and fsck

[Stefan Monnier]

>>>> filesystem... so considering its size, I'd turn it off. Hopefully the
>>>> "fsck takes _forever_" problem will die when btrfs becomes the
>>>> standard filesystem.
>>> Just a reminder: Linux has xfs since 2002. A full-blown fsck on xfs is
>>> a rare thing.
>> Similarly, I don't know of any case where fsck on an ext3 partition
>> turned out to be useful.  As a matter of fact, my home router's ext3
> I wouldn't go that far. It all depends what messed the file system up in the
> first place.

That's the thing: nothing did.  So why run fsck at all?

> Ext3 bugs, minor scribbling and suchlike generally get tidied up
> reasonably well by e2fsck.  It's quite true that with major corruption
> to the file system there's often not an awful lot left afterwards but
> that's true of many other file systems as well.

Oh, you're thinking of using fsck for recovery purposes.
That's a different situation.  I was just talking about the idea of "not
needing to do fsck any more", which is pretty much already the case for
XFS and ext3, AFAIK.

>> partition is never fsck'd (it would take way too much time to this poor
>> 266MHz thingy to fsck my 1TB filesystem).
> /me wonders why a router needs a 1TB fs :-)

Actually I call it "router" because it was sold as such and it replaced
a machine which I originally used as such as well.  Really it's just
a small home server which stores&plays my music, stores my movies and
other such things, ...  It doesn't actually do any routing at all.


        Stefan

Re: [linux-lvm] Re: About fstab and fsck

[Bryn M. Reeves]

Stefan Monnier wrote:
>>>>> filesystem... so considering its size, I'd turn it off.
>>>>> Hopefully the "fsck takes _forever_" problem will die when
>>>>> btrfs becomes the standard filesystem.
>>>> Just a reminder: Linux has xfs since 2002. A full-blown fsck
>>>> on xfs is a rare thing.
>>> Similarly, I don't know of any case where fsck on an ext3
>>> partition turned out to be useful.  As a matter of fact, my
>>> home router's ext3
>> I wouldn't go that far. It all depends what messed the file
>> system up in the first place.
> 
> That's the thing: nothing did.  So why run fsck at all?

I read your statement to mean running fsck on a broken file system
didn't do anything useful. If it's not broken, don't fix it. :)

>> Ext3 bugs, minor scribbling and suchlike generally get tidied up 
>> reasonably well by e2fsck.  It's quite true that with major
>> corruption to the file system there's often not an awful lot left
>> afterwards but that's true of many other file systems as well.
> 
> Oh, you're thinking of using fsck for recovery purposes. That's a
> different situation.  I was just talking about the idea of "not 
> needing to do fsck any more", which is pretty much already the case
> for XFS and ext3, AFAIK.

Ah, you mean the regular mount count / interval checks? Yes, theses
should be unnecessary with a journaled file system (this is why
anaconda has disabled those checks for file systems that it creates
for years).

The paranoid might still like to run these checks occasionally to
detect any latent corruption but I'd be much more inclined to do that
on my systems if we had an fsck that ran in a reasonable amount of
time for large volumes.

> Actually I call it "router" because it was sold as such and it
> replaced a machine which I originally used as such as well.  Really
> it's just a small home server which stores&plays my music, stores
> my movies and other such things, ...  It doesn't actually do any
> routing at all.

Ah, cool; I have a similar box (although it does do some routing) that
also has a fairly sizeable file system. Currently it's configured to
never fsck on boot for the reasons discussed here.

Regards,
Bryn.

Re: [linux-lvm] Re: About fstab and fsck

[David Robinson]

On Thu, Feb 12, 2009 at 8:13 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> filesystem... so considering its size, I'd turn it off. Hopefully the
>>> "fsck takes _forever_" problem will die when btrfs becomes the
>>> standard filesystem.
>
>> Just a reminder: Linux has xfs since 2002. A full-blown fsck on xfs is
>> a rare thing.
>
> Similarly, I don't know of any case where fsck on an ext3 partition
> turned out to be useful.  As a matter of fact, my home router's ext3
> partition is never fsck'd (it would take way too much time to this poor
> 266MHz thingy to fsck my 1TB filesystem).

I've seen plenty of cases that fsck has made a filesystem consistent
again, but like Bryn says, there's only so much it can do.

from e2fsck(8):

e2fsck is used to check a Linux second extended file system (ext2fs).
E2fsck also supports ext2 filesystems containing a  journal, which are
also sometimes known as ext3 filesystems, by first applying the
journal to the filesystem before continuing with normal e2fsck
processing.  After the journal has been applied, a filesystem will
normally be marked as clean. Hence, for ext3 filesystems,
e2fsck will normally run the journal and exit, unless its superblock
indicates that further checking is required.

So the fsck that is done at boot time only replays the journal if a
filesystem wasn't unmounted cleanly. Its only when after replaying the
journal that if further checking is required a full fsck (the one that
takes forever) is needed. If a full fsck is needed you'll be dropped
to emergency mode (or something) where you need to enter your root
password and run the full fsck (at least that's how it works in RHEL
and Fedora).

--Dave

[linux-lvm] Re: About fstab and fsck

[f-lvm]

Hardware does go bad.  It can affect journaling filesystems as well.
The ext3 manpage points out that there are plenty of things that can
wreck your filesystem even if the software is perfect, and that you'd
probably want to know if it was being slowly munched away -before- it
finally goes south completely.  (For example, subtle memory errors can
gradually turn your FS into garbage, but it may take a while to notice.
Capacitors slowly going bad on a motherboard that lead to corruption
due to poor power-supply bypassing; vibration leading to submicrosecond
faults in solder joints and connectors...  The list is endless.)

Some filesystems are far more vulnerable to single-bit errors than
others, so some may fall over long before it would occur to you to
run fsck if you run it "only when there's a problem".  ext3 is more
paranoid of bad hardware than some other popular journalling filesystems,
so in fact you might be well-advised to run fsck -more- frequently on
others.  (Just be careful---for hilarity's sake, try copying an entire
reiserfs filesystem into an ordinary file on a second reiserfs, and
then run fsck on -that-.  Make sure your backups are readable first;
you'll need 'em.  http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
has details, and XFS doesn't come off too well in that, either.)

For that matter, subtle hardware issues might eat the data in your
files, bit by bit, and you might never notice unless it was starting
to eat your metadata and you wondered why fsck kept finding small
errors.  It depends on whether you care whether your data might have
a few bits of corruption scattered through it.

I recently hit an issue where a motherboard had issues with (a) CPU
throttling (flipped some RAM bits when the CPU was in "slow" mode),
-and- (b) with dual-channel memory (flipped some bits, even after the
throttling was turned off, if the RAM was in dual-channel mode but not
if it was in single-channel mode---no version of memtest86+ was ever
able to detect the corruption, but repeated runs of "fsck -n" on the
(terabyte) FS yielded -different- results every time!).  And this was
on top of an encrypted device, so it was quite clear that it wasn't
bad bits on the disk or in any of the disk datapaths.

[(a) above was repeatable when reading from a USB stick and both SATA
and IDE, which pretty much nailed the coffin shut and was about when I
found out the problem was throttling---repeated md5sum on files with
certain bit patterns yielded nondeterministic results if run on an
idle machine ten seconds apart, but running them in a tight loop
yielded the same results after the first few "random" results, as
did nailing the CPU in another process even if the md5sums were
seconds apart.  But (b) didn't manifest -at all- except in fsck,
and I -ran- the fsck because I thought (a) might have already
trashed the filesystem and I wanted to find out whether it had.]

Without fsck, I'd never have discovered the dual-channel problem until
it had completely trashed the data (instead of discovering it "only" a
month after installing some new RAM -and- thoroughly "testing" it with
memtest86+ before putting the machine back in service---memtest86+'s
tests didn't discover the dual-channel problem despite days of runtime
-and- never noticed throttling issues because, of course, it runs the
CPU flat-out all the time...).

One thing you might want to consider is whether your backups go at
least far back in time as the last time you ran fsck.  If they don't,
and fsck discovers that bad hardware has been corrupting your data,
you're screwed.  OTOH, running fsck more frequently might mean you
don't need to keep complete backups quite as far back.

Since this is the LVM list, I'm assuming that y'all are actually, you
know, -running- LVM.  And if you are, you can make a snapshot of your
filesystem and run "fsck -n" -on the snapshot- so you don't even have
to take the FS out of service; if it finds a serious problem, then you
can dismount it and run a real fsck to fix it.  Sure, the system will
be slower while fsck is running, but you can ionice it and/or run it
at slack(er) times or whatever else can mitigate its impact, and it
doesn't matter how long it takes to run if it's running readonly off
a snapshot...

Re: [linux-lvm] Re: About fstab and fsck

[Martin Schröder]

2009/2/13  <f-lvm@media.mit.edu>:
> For that matter, subtle hardware issues might eat the data in your
> files, bit by bit, and you might never notice unless it was starting
> to eat your metadata and you wondered why fsck kept finding small
> errors.  It depends on whether you care whether your data might have
> a few bits of corruption scattered through it.

Which is why ZFS was invented, and we are hoping for btrfs. You need
checksums when you use pc-level rotating rust for storing data.

Best
   Martin

[linux-lvm] SCSI error: return code = 0x00070000 - device-mapper: multipath

[Mark Reardon]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]



Hi All,

Has anybody every come across this error?  Does anybody know what it meens?

Thanks,

Regards,

Mark


_________________________________________________________________

MSN straight to your mobile - news, entertainment, videos and more.

http://clk.atdmt.com/UKM/go/147991039/direct/01/

[-- Attachment #2: Type: text/html, Size: 497 bytes --]

[linux-lvm] Re: SCSI error: return code = 0x00070000 - device-mapper: multipath

[Bryn M. Reeves]

On Thu, 2009-06-11 at 11:00 +0100, Mark Reardon wrote:
> 
> Hi All,
> 
> Has anybody every come across this error?  Does anybody know what it
> meens?

That's not really enough information to diagnose the problem. The error
you're seeing comes from the SCSI layer. It's got the value 0x07
(DID_ERROR) in the host byte which is set by the low level driver.

Were any other scsi messages logged around the time of this?

It'd also help to know the kernel and multipath-tools versions that you
are running as there have been changes in how the kernel deals with
transient errors in a multipath configuration over time.

Regards,
Bryn.