Re: synchronous metadata update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Pradeep,

On Mon, Dec 22, 2008 at 3:15 PM, pradeep singh
<pradeep.rautela@xxxxxxxxx> wrote:
> On Mon, Dec 22, 2008 at 3:10 PM, Sandeep K Sinha
> <sandeepksinha@xxxxxxxxx> wrote:
>> Hi pradeep,
>>
>> On Mon, Dec 22, 2008 at 2:54 PM, pradeep singh
>> <pradeep.rautela@xxxxxxxxx> wrote:
>>> On Sun, Dec 21, 2008 at 7:52 PM, Sandeep K Sinha
>>> <sandeepksinha@xxxxxxxxx> wrote:
>>> [snip]
>>>>>
>>>>
>>>> When you say a file system as consistent, It means that you would be
>>>> able to mount the filesystem. The superblock would be in the
>>>> consistent state.
>>>> The point is that even if you loose the data for a couple of files,
>>>> still your file system will be up and you would be able to access the
>>>> data for other files.
>>>> If you loose the consistency of a file system( e.g superblock) then
>>>> would loose everything.
>>>>
>>>> There are other tools that can be used to recover the data of a file
>>>> or revert back the file to a consistent state but if you loose
>>>> superblock then you land NOWHERE.
>>>
>>> Perfectly right but that may be a one off scenario. Usually modern
>>> filesystems would keep multiple copies of superblock, so even if your
>>> superblock is damaged you can still recover the fs to a sane state by
>>> forcing fsck to use an alternative superblock.
>>>
>>> Hope this helps somehow.
>>>
>>
>> No offense, but remember that fsck fails too.
>> There are instances where this is possible.
>
> Can you please describe any scenario, where this may happen?
> One i can think of is when your /sbin is groked.
>
Well, there can be many scenario's which may lead to such situations.
In commodity file systems liek ext2/ext3 we dont handle sector failures.
If such in-consistency occurs at your fs level, then you will be in
big problems.

Also, there can be possible situations where your superblock gets
corrupted and the fsck wont have any information pertaining to the
disk layout of the Fs.
In such scenario, you won't even have access to the duplicate SB's.

Duplicate SB's are helpful mostly when you have some kind of
inconsistencies in the SB data but when the SB itself is corrupted,
who will tell you where the alternative SB is ?

> I wonder if this is the case, then what happens when fsck itself
> cannot be invoked. though your superblock is intact you still cannot
> have a sane state for your fs because effectively fsck is not there.
> How do we handle such situations?

Obviously you will have to have something like a fsck.
Look for some other similar tools.
Also, if fsck fails for its own reason, it will probably be temporary, I assume.
> Any hints?
>


> Thanks for the inputs Sandeep,
>    ~Pradeep
>>
>> HTH,
>>
>>> Thanks,
>>>       ~Pradeep
>>>>
>>>>>
>>>>> Thanks
>>>>> Shyam.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Sandeep.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> "To learn is to change. Education is a process that changes the learner."
>>>>
>>>> --
>>>> To unsubscribe from this list: send an email with
>>>> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
>>>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Pradeep
>>>
>>
>>
>>
>> --
>> Regards,
>> Sandeep.
>>
>>
>>
>>
>>
>>
>> "To learn is to change. Education is a process that changes the learner."
>>
>
>
>
> --
> Pradeep
>



-- 
Regards,
Sandeep.





 	
"To learn is to change. Education is a process that changes the learner."

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux